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EXECUTIVE  SUMMARY 


Introduction 

Identity  Management  (IdM)  has  existed  throughout  history  to  serve  both 
public  and  private  purposes.  It  has  continuously  evolved  to  match  changing  opera¬ 
tional  needs,  to  take  advantage  of  new  capabilities,  and  to  stay  consistent  with  the 
societal  conventions  of  the  day.  The  most  recent  advancement  in  IdM  has  been  its 
transition  into  the  modern  digital  world,  which  has  provided  a  wealth  of  previ¬ 
ously  impossible  capabilities  to  support  both  security  and  convenience  needs. 
Digital  IdM  systems  are  becoming  increasingly  commonplace,  and  their  explosive 
growth  is  expected  to  continue. 


For  the  purposes  of  this  Task  Force,  Identity  Management  means  “the 
combination  of  technical  systems,  rules,  and  procedures  that  define  the  owner¬ 
ship,  utilization,  and  safeguarding  of  personal  identity  information.  The  primary 
goal  of  the  IdM  process  is  to  assign  attributes  to  a  digital  identity  and  to  connect 
that  identity  to  an  individual.”  The  terms  of  reference  for  this  Task  Force  are  at 
Annex  A. 


To  date,  this  growth  has  been  driven  by  the  need  to  meet  independent  mis¬ 
sion  needs  (including  both  screening  applications  and  access  control).  As  these 
missions  continue  to  expand,  overlaps  across  missions  will  become  more  and 
more  pervasive.  This  is  an  undeniable  truth,  as  all  IdM  systems  relate  back  to  an 
individual  —  actions  taken  within  one  system  will  potentially  impact  data  and/or 
decisions  in  other  systems.  A  holistic,  cross-mission  analysis  and  planning  cycle 
has  not  previously  been  performed,  presumably  because  of  the  tremendous  scope 
of  the  task  and  the  duty’s  inherent  social  sensitivity.  This  daunting  task  was  as- 
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signed  to  the  National  Science  and  Technology  Council’s  (NSTC)  Task  Force  on 
Identity  Management  (Task  Force),  as  a  continuation  of  independently  developed 
and  managed  government  IdM  systems  will  encounter  operational,  technological, 
and  privacy  issues  that  will  become  increasingly  difficult  to  manage. 

The  Task  Force’s  scope  was  limited  to  federal  government  systems,  with 
the  full  understanding  that  these  systems  frequently  rely  on  and  impact  IdM  sys¬ 
tems  beyond  federal  control.  This  report  presents  an  overview  of  the  current  state 
of  federal  IdM  systems  and  also  presents  a  high-level  vision  of  how  these  systems 
can  be  holistically  designed  to  provide  better  services  while  increasing  privacy 
protection.  The  purpose  of  this  report  is  to  initiate  further  discussion  on  this  vi¬ 
sion,  inform  policy  decisions,  and  provide  direction  on  which  to  base  near-term 
research. 

Task  Force  Work 


The  Task  Force  was  chartered  to  study  federal  IdM  over  a  six-month  pe¬ 
riod,  with  a  broad  range  of  representation  from  different  government  missions, 
and  was  given  three  primary  tasks: 

•  Provide  an  assessment  of  the  current  state  of  IdM  in  the  U.S.  gov¬ 
ernment; 

•  Develop  a  vision  for  how  IdM  should  operate  in  the  future; 

•  Develop  first-step  recommendations  on  how  to  advance  toward 
this  vision. 

The  Task  Force  undertook  two  overlapping  approaches  to  determine  the 
current  state  of  IdM  in  the  U.S.  government,  a  detailed  assessment  of  publicly 
available  Privacy  Impact  Assessments  and  an  OMB-issued  survey  to  the  Federal 
Chief  Information  Officers’  Council.  The  combined  analysis  showed  that  there  are 
more  than  3,000  systems  within  the  U.S.  government  that  utilize  Personally  Iden¬ 
tifiable  Information  (PII),  and  the  vast  majority  of  these  were  designed  and  are 
managed  independently  from  one  another.  These  facts  contribute  to  several  issues 
with  the  current  state: 
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•  Duplicative  identity  data  is  often  stored  in  multiple  locations  with¬ 
in  the  same  agency,  as  well  as  across  agencies,  causing  a  negative 
impact  on  accuracy  and  complicating  an  individual’s  attempt  at  re¬ 
dress; 

•  A  lack  of  commonly  used  standards  makes  appropriate  cross¬ 
function  collaboration  difficult,  thus  impacting  both  time-sensitive 
mission  needs  as  well  as  reducing  personal  privacy; 

•  Privacy  protection  efforts  vary  in  complexity  across  agencies; 

•  There  is  no  single  government-wide  forum  responsible  for  coordi¬ 
nating  and  homogenizing  IdM  efforts  across  the  U.S.  government. 

The  IdM  Task  Force’s  vision  for  the  future  is  a  substantially  more  organ¬ 
ized  Identity  Management  framework.  A  fundamental  precept  for  this  vision  is  a 
realization  that  not  all  PII  is  created  equal.  Some  PII  will  be  useful  for  broad 
range  of  applications,  while  others  are  only  useful  within  the  context  of  a  specific 
application  and  should  not  be  shared  outside  that  application.  PII  within  both  of 
these  categories  also  have  varying  levels  of  sensitivity  and  should  be  managed 
accordingly. 

The  Task  Force’s  vision  includes  a  federated  approach  for  leveraging 
broad-use  PII  elements  to  maximize  accuracy,  availability,  privacy  protection,  and 
management  of  this  data.  Individual  applications  would  access  this  data  through  a 
network  grid,  which  can  be  established  using  common  technical  standards  and 
policies  to  ensure  appropriate  use  and  control.  Once  verified,  broad-use  PII  can  be 
augmented  with  application-specific  PII  in  order  to  make  operational  decisions. 
To  this  end,  we  make  the  following  assumptions: 

•  Identity  and  the  management  of  all  the  personal  identifiable  quali¬ 
ties  of  identity  information  are  considered  a  critical  asset  in  sustaining 
our  security  posture; 

•  To  the  extent  available  and  practicable,  a  very  high  confidence  in 
an  asserted  identity  is  recommended  as  the  basis  for  authorization  for 
access  to  government  applications  regardless  of  assurance  level  re- 
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quired.  For  example,  Personal  Identity  Verification  (PIV)  credentials 
required  by  HSPD-12  and  used  by  federal  employees  and  contractors 
are  available  and  provide  for  a  very  high  level  of  confidence  and  could 
be  used  for  accessing  all  applications  —  even  those  requiring  lower 
levels  of  assurance; 

•  There  is  an  expectation  that  revocation  of  identity  data  and  the  re¬ 
lated  authorizations  are  executed  in  accordance  with  government-wide 
standards  throughout  all  applications  (whether  used  to  support  logical 
or  physical  access); 

•  There  is  an  understanding  that  management  and  protection  of  iden¬ 
tity  is  not  the  responsibility  of  any  one  or  a  few  federal  agencies,  but 
rather  the  responsibility  of  all  federal  agencies  to  enable.  Identity  is  a 
component  of  each  and  every  transaction.  If  one  federal  agency  fails  to 
carry  out  their  responsibility,  access  to  our  networks  and  facilities  will 
be  significantly  jeopardized. 

Several  top-level  goals  and  characteristics  for  the  government’s  proposed 
state  of  IdM  can  thus  be  described  as: 

•  Configuration  and  operation  of  a  “network  of  networks”  to  se¬ 
curely  manage  digital  identities,  based  on  a  set  of  common  data 
elements  for  stored  PII  that  will  allow  it  to  be  leveraged  by  a  broad 
range  of  applications; 

•  Security  of  process,  data  transmission,  and  storage;  this  includes 
and  embraces  all  features  of  confidentiality,  integrity,  authenticity, 
and  privacy,  including  use  of  encryption  and  multifactor  authenti¬ 
cation; 

•  Auditability  of  processes,  with  complete,  automatic,  and  secure  re¬ 
cord  keeping; 

•  Ubiquitous  availability,  at  global  distances,  of  strong  verification 
of  stored  digital  identity  when  called  for  or  needed  to  support  an 
authorized  application; 

•  Standards-based  connectivity,  interoperability,  and  extensibility  of 
supporting  IT  architecture; 
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•  Preservation  of  application-specific  PII  data  under  control  of  appli¬ 
cation  sponsors,  with  minimal  exposure  to  unauthorized  access  or 
unnecessary  transmission  across  networks; 

•  Ability  of  prospective  application  sponsors  to  develop,  install,  and 
operate  applications  in  a  way  that  permits  the  supporting  IT  grid  to 
be  seen  as  a  freely  available,  ubiquitous  service. 

The  above  elements  fonn  the  tenets  of  a  strategy  to  manage  and  protect 
identity  within  all  federal  agencies.  Anticipated  benefits  over  the  current  state  in¬ 
clude: 

•  Enhanced  accuracy  and  management  of  PII  that  is  used  by  multiple 
applications; 

•  Clear  separation  of  application-specific  PII  and  tighter  controls  to 
ensure  this  information  isn’t  shared  across  domains; 

•  A  uniform,  more  transparent  approach  of  handling  PII; 

•  Minimization  of  duplicative  efforts  to  generate,  maintain,  and  sa¬ 
feguard  PII; 

•  Providing  the  government  a  better  understanding  of  and  ability  to 
macro-manage  its  IdM  activities. 

This  report  offers  a  set  of  recommendations  (see  Section  4)  organized  into 
specific  subject  areas  as  follows: 

•  Standards  and  Guidance; 

•  Architecture; 

•  Science  and  Technology  Considerations; 

•  Government-wide  Coordination. 

The  Science  and  Technology  recommendations  may  be  acted  upon  imme¬ 
diately,  as  the  success  of  those  efforts  will  impact  further  analyses  and  policymak¬ 
ing  required  to  provide  depth  and  direction  to  the  Task  Force’s  initial  vision. 
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Toward  that  end,  the  Task  Force  recommends  an  enduring  IdM  forum  to  visualize 
and  address  IdManagement  issues  holistically,  in  policy  and  technology.  This 
process  should  seek  to  frame  the  governmental  agenda  in  this  broad  area,  inform 
the  standards  and  guidance  development  activities,  and  guide  the  further  refine¬ 
ment  of  the  IdM  architecture.  In  so  doing,  it  should  guide  activities  that  will  ex¬ 
pand  and  refine  our  total  understanding  and  support  the  development  of  consensus 
within  an  informed  public  regarding  the  whole  range  of  IdManagement  issues  and 
opportunities  within  the  federal  enterprise. 

Conclusion 

It  is  important  to  note  that  the  Task  Force  does  not  see  this  report  as  being 
the  “final”  analysis  of  the  IdM  needs  of  the  federal  government,  nor  is  it  consid¬ 
ered  to  be  a  comprehensive  treatment  of  the  subject  in  a  level  of  detail  sufficient 
to  determine  formal  policy.  Rather,  it  is  an  initial  study  that  provides  a  common 
foundation  and  vision  on  which  to  base  future  research,  discussions,  studies,  and, 
eventually,  policymaking.  The  Task  Force  aimed  to  make  this  report  as  intellectu¬ 
ally  comprehensive  as  possible  within  available  time  and  resources,  seeking, 
above  all,  to  recognize  and  treat  IdM  in  its  full  dimensions,  including  its  growing 
importance  to  the  conduct  of  government. 

In  contemplating  the  current  state  of  IdM  in  the  federal  government,  and 
thinking  about  the  future  direction,  one  may  paraphrase  Winston  Churchill: 

“It  is  not  the  end,  nor  even  the  beginning  of  the  end;  but  it  is,  perhaps,  the 
end  of  the  beginning...  ” 
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1  INTRODUCTION 


Identity  Management  (IdM)  is  a  topic  that  has  grown  rapidly  and  adapted 
significantly  in  recent  years.  Although  the  underlying  processes  have  been  in  use 
for  centuries,  the  term  itself  is  a  relatively  recent  invention,  created  in  response  to 
the  need  to  collectively  address  issues  encompassing  related  areas  of  technology, 
policy,  and  process.  Components  of  IdM  systems  include  biometrics,  identity 
cards,  and  user  ID/passwords/personal  identification  numbers  (PIN)  to  support 
access  control  (both  physical  and  logical)  and  supporting  information  technology 
(IT)  architectures.  To  all  of  this  must  be  added  a  wealth  of  law,  regulation,  policy, 
and,  above  all,  awareness  of  and  sensitivity  to  the  attitudes  and  views  of  the  or¬ 
ganizations  —  including  society  itself —  within  which  such  systems  are  proposed 
to  be  installed  and  operated.  Within  the  latter,  preservation  of  rights  and  privileges 
and  protection  of  privacy  are  of  foremost  importance. 

The  underlying  function  of  identification  has  been  a  part  of  the  human  ex¬ 
perience  since  the  growth  of  social  complexity  introduced  differentiated  roles, 
rights,  privileges,  and  resources  into  communities.  Some  of  these  “unique  abili¬ 
ties”  came  with  membership  of  a  class  or  group,  while  others  represented  individ¬ 
ual  characteristics.  Sometimes  there  was  an  identifying  badge,  mark,  object,  or 
other  way  to  visually  distinguish  the  individual  with  a  specific  role;  sometimes 
this  could  only  be  known  from  personal  interaction. 

In  modem  times,  society  has  developed  systems  to  characterize  individu¬ 
als  for  purposes  of  establishing  their  authorizations  (e.g.,  driver’s  license),  support 
security  needs  (e.g.,  fingerprint  matching  as  an  aspect  of  criminal  investigation), 
or  to  streamline  delivery  of  specific  services  or  entitlements  (e.g.,  Social  Security 
number).  In  the  absence  of  a  purpose-built  IdM  framework,  these  have  sometimes 
been  used  as  de  facto  “ID  systems,”  with  uneven  results. 

Even  more  recently,  the  advent  of  the  digital  age  has  seen  the  explosive 
proliferation  of  citizen-level  ability  to  access  information  and  resources  globally 
via  the  Internet.  As  the  Internet  became  a  preferred  mechanism  for  many  indi¬ 
viduals  to  receive  infonnation,  communicate,  and  conduct  business,  official  or¬ 
ganizations  responded.  In  the  name  of  customer  convenience,  they  began  to 
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design  computer  network-accessible  tools  and  resources  to  perfonn  functions 
once  only  achievable  through  in-person  interaction  with  government  officials  in 
their  offices.  The  proliferation  of  these  online  services  exploded  and  continues  to 
do  so  today. 

The  response  to  the  terrorism  acts  of  9/1 1  and  other  events  has  made  secu¬ 
rity  screening  part  of  many  processes  and  activities;  the  ability  to  conduct  such 
screening  effectively  relies  heavily  on  the  availability  of  standard  and  secure  iden¬ 
tity  documentation.  The  enormous  proliferation  of  the  number,  nature,  location, 
and  frequency  of  such  checks  poses  a  challenge  in  itself,  regarding  the  design  of 
scalable  and  accurate  systems  to  support  screening  needs. 

Individuals  became  victims  of  “identity  theft”  and  frauds  of  many  types, 
since  they  were  now  dealing  with  resources  worth  trying  to  steal.  Federal  organi¬ 
zations,  increasingly  dependent  on  networked  online  resources  and  tools  to  con¬ 
duct  the  business  of  government,  became  concerned  about  the  vulnerability  of 
these  systems  to  cyber  attack,  and  the  increasingly-serious  consequences  if  such 
attacks  could  be  conducted  successfully.  Over  time,  these  “negative  motivators” 
have  become  matters  of  increasing  concern. 

At  the  same  time,  however,  the  development  of  better  and  more  widely 
accessible  capabilities  to  access  information  and  do  useful  work  made  the  online 
domain  more  attractive  as  a  place  to  conduct  serious  business.  This  included  sup¬ 
port  to  processes  in  ways  that  had  never  been  possible  before.  The  “upside  poten¬ 
tial”  of  safe  and  secure  transactions,  continuously  accessible  at  any  distance, 
began  to  take  substance. 

In  so  doing,  the  importance  of  establishing  one’s  identity  to  support  these 
interactions  became  increasingly  important.  At  this  point,  the  casual  manner  of 
“identification”  employed  up  until  that  time  often  became  insufficient  to  establish 
the  trusted  relationship  required  for  these  transactions.  Beyond  these  considera¬ 
tions  related  to  individuals  who  are  “U.S.  persons  and  others  known  as  friendly,” 
the  federal  government’s  total  IdM  must  also  include  the  ability  to  detect  and  re¬ 
detect  (if  previously  having  been  ascertained  to  represent  a  threat)  persons  who 
place  American  citizens  or  facilities  at  risk.  The  identification  data  related  to  these 
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may  be  tenuous,  ambiguous,  incomplete,  and  may  not  conform  to  any  specific 
technical  fonnats  or  standards.  A  major  function  of  the  total  IdM  system  is  to  fa¬ 
cilitate  the  development  of  speedy  and  accurate  judgments  regarding  such  threats, 
using  all  available  and  relevant  infonnation. 

Finally,  there  are  persons  who  are  “unknown”  in  terms  of  their  security 
risk,  in  that  they  have  neither  been  vetted  through  governmental  processes  to  es¬ 
tablish  in  their  trust  identity  assertions  (e.g.,  HSPD-12/FIPS-201  standards)  nor 
demonstrated  any  hostile  intent  or  actions.  Data  regarding  these  persons  are  now 
being  collected  under  the  authority  of  various  programs  associated  with  border 
controls  or  foreign  national  security  operations.  These  people  are  considered  “un¬ 
knowns,”  for  our  purposes. 

These  various  needs  for  security,  privacy,  access,  service,  and  the  ability  to 
take  advantage  of  emergent  capabilities  all  come  together  in  the  modern  concept 
of  IdM. 


IdM  is  now  beginning  to  emerge  in  ways  appropriate  to  its  potential.  That 
potential  includes  the  achievement  of  valuable  benefits  and  new  capabilities  with 
improvements  that  can  be  measured  in  several  ways.  At  the  same  time,  IdM  will 
enhance  personal  freedoms,  privacy,  and  self-determination,  relative  to  the  status 
quo,  for  the  conduct  of  such  matters. 

This  Task  Force’s  purpose  is  to  better  understand  and  report  on  the  poten¬ 
tial  that  IdM  offers  to  improve  performance  of  the  full  range  of  government  func¬ 
tions,  and  to  seek  understanding  of  the  transfonnation  in  these  matters  that 
modem  global  telecommunications  connectivity  has  precipitated.  From  this,  the 
Task  Force’s  recommendations  will  seek  to  identify  investment  and  policy  priori¬ 
ties  that  will  wisely  guide  the  government  forward  in  this  area. 

1.1  PURPOSE 

The  purpose  of  this  report  is  to: 

•  Inform  policy  makers  and  the  public  regarding  the  issues  and  op¬ 
portunities  associated  with  IdM; 
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•  Homogenize  the  IdM  discussion  within  and  across  government,  by 
seeking  to  establish  common  terms,  goals,  and  standards  for  the 
whole  subject  area; 

•  Provide  a  vision  of  the  future  application  and  use  of  IdM  in  the 
federal  government,  for  future  consideration  by  agencies,  subse¬ 
quent  studies,  and  policymaking  bodies; 

•  Demonstrate  that  privacy  may  be  improved  relative  to  the  status 
quo,  while  transitioning  identity-related  activities  into  rigorous  and 
accountable  IT-based  applications; 

•  Develop,  identify,  and  list  some  of  the  most  immediate  needs  in  re¬ 
search  and  development,  standards  development,  technical  policy, 
and  technology  architecture,  as  needed  to  achieve  these  outcomes. 
Advancing  science  and  technology  in  this  way  will  enable  agencies 
to: 

o  Improve  the  performance  of  existing  systems  and  processes,  as 
now  fielded,  in  ways  involving  minimal  time,  effort,  and  ex¬ 
pense; 

o  Modify  existing  systems  to  enhance  functionality  and  scalabil¬ 
ity; 

o  And  devise  new  approaches  to  extend  usable  and  responsive 
IdM  service  to  the  whole  set  of  users  and  their  identity  assur¬ 
ance  needs. 

1.2  BACKGROUND  AND  TASK  FORCE  CHARTER 

Over  time,  persons  and  organizations  have  sought  to  design  means  to  iden¬ 
tify  individuals  for  a  broad  range  of  purposes. 

The  techniques  and  technologies  that  have  supported  these  efforts  have  va¬ 
ried  widely  and  continue  to  do  so  today.  The  general  trend  has  been  for  these  me¬ 
chanisms  to  become  more  rigorous  and  complex  over  time  as  technology  has 
advanced.  At  the  same  time,  there  remains  a  general  understanding  that  the  same 
level  of  confidence  is  not  needed  for  every  identity  assurance  activity  and  applica¬ 
tion.  Through  all  of  this,  there  have  been  several  basic  premises: 
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•  Regardless  of  the  method  used  by  individuals  in  remote  settings  to 
assert  their  identity  (and,  thus,  rights  or  privilege  of  every  sort)  to 
an  application  or  access  control  system,  some  knowledge  of  the 
granting  and  status  of  these  privileges  was  maintained  in  a  separate 
and  distinct  location,  often  by  the  granting  authority; 

•  If  and  when  changing  circumstances  altered  the  privileges  of  the 
remote  user  previously  authorized  for  such  purposes,  changes  only 
took  effect  when  they  could  be  authoritatively  communicated  to 
the  remote  application  or  access  control  system  by  the  granting  au¬ 
thority; 

•  As  such,  if  some  emergent  problem  associated  with  a  user  de¬ 
manded  action  in  less  time  than  it  took  the  real  authority  to  re¬ 
spond,  then  local  initiative  was  necessary;  this  approach  sometimes 
worked  but  opened  the  way  to  abuse  and  excess; 

•  These  systems  —  a  defined  set  of  roles  and  privileges,  linked  to  a 
granting  and  controlling  authority  who  maintained  some  kind  of 
records  about  the  process  —  tended  to  proliferate.  The  extent  and 
nature  of  the  data  required  to  support  these  systems  was  generally 
unique;  this  led  to  the  creation  of  redundant,  parallel  “stovepipes,” 
or,  in  some  cases,  communications  channels  between  the  granting 
authority  and  the  remote  activity. 

And  so  the  IdM process  has  remained  until  very  recently,  by  and  large,  a 
process  where: 

•  Information  is  collected  and  stored  to  establish  eligibility,  entitle¬ 
ment,  or  to  confer  authority  on  persons  who  are  to  be  embraced 
within  a  specific  IdM  system; 

•  Those  persons  are  empowered  in  various  ways  by  the  authority 
controlling  the  role  or  privilege  involved;  they  are  often  provided 
with  some  physical  token  of  that  role  to  aid  them  in  asserting  the 
granted  privilege  when  at  a  distance  from  the  actual  authority. 

•  As  the  authority  manages  the  process,  he/she  may  add,  delete,  or 
alter  persons  or  authorities  to  the  system; 
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•  Such  changes  take  effect  with  variable  ease,  speed,  and  confidence, 
depending  on  the  connection  between  the  authority  and  the  popula¬ 
tion  embraced  within  the  system; 

•  All  of  this  is  done  largely  in  parallel,  by  various  subject-matter- 
specific  IdM  systems,  with  the  cost  and  effort  of  collecting  and 
managing  all  information  and  transactions  replicated  in  each  one. 
The  result  is  similar  to  the  situation  depicted  in  Figure  1. 


Current  IdM 

Architectural  Model 

IDENTITY  APPLICATION,  e  g 

-  Physical  Access 

-  Logical  Access 

-  Personal  Admin. 

-  Healthcare 

-  Military  Operations 

-  Counter-terrorism 

-  Border/perimeter 
Screening 

-  Criminal  Investigation 
-Etc. 


Supporting  Stored  10  Data 


Figure  1.  Current  IdM  Architectural  Model 

As  noted,  one  aspect  of  IdM  relates  to  security  screening  processes  of  one 
sort  or  another,  however,  there  is  another,  widely  used  aspect  of  IdM  that  is  con¬ 
cerned  with  establishing  identity  in  order  to  conduct  business.  The  true  value  of 
an  IdM  system  is  realized  when  it  is  used  to  empower  service  providers,  such  as 
the  federal  government,  to  flexibly  control  access  to  applications  and  information, 
empowering  the  network  grid  to  support  persons  in  the  conduct  of  their  profes- 
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sional  and  personal  business,  and  apply  resources  to  uses  of  their  choosing.  These 
value-added  applications  of  IdM  offer  measurable  savings  in  time  and  money.1  f 
designed  wisely,  these  allow  individuals  to  largely  control  the  nature  and  extent  of 
their  own  participation  in  identity  assurance  processes.  To  some  extent,  this  can 
be  based  on  voluntary  enrollment  on  the  basis  of  value  recognizable  to  them  per¬ 
sonally. 


Most  recently,  advancements  in  IT  plus  evolution  in  the  nature  of  and  in¬ 
creasing  need  for  security  screening  have  led  the  federal  govermnent  to  develop  a 
number  of  ID-related  programs  for  specific  applications  and  groups  of  people. 
These  programs  have  driven  recognition  that  relates  to  the  historic  approaches 
outlined  above.  IdM  in  America  today  must  be: 

•  Adaptive,  responsive,  and  universally  accessible; 

•  Attuned  to  social  acceptability  and  privacy,  so  as  to  be  embraced 
and  genuinely  valued  by  its  users; 

•  Extensible  in  scale  (numbers)  and  scope  (different  types  of  activi¬ 
ties  it  can  embrace),  due  to  explosively  growing  need  and  interest, 
even  by  many  who  may  lack  deep  technical  training  or  experience; 

•  Easy  to  use  and  maintain,  for  the  same  reasons; 

Secure  and  effective,  leaving  minimal  risk  of  exploitation,  alteration,  or 
misuse  at  any  level  of  the  system,  and  allowing  all  parties  to  be  confident  of  its 
use. IdM  in  America  today  can  be: 

•  All  but  invisible  to  the  end-user,  even  while  being  ubiquitously 
available;  Of  genuine,  measurable  value  to  individual  users  and 
“application-sponsoring”  organizations  and  authorities  (those 


1  See  OMB  Memorandum  M-06-22,  “ Cost  Savings  Achieved  Through  E-Government  and  Line  of 
Business  Initiatives .” 
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whose  roles  and  powers  allow  or  compel  them  to  organize  the  per¬ 
formance  of  some  identity-based  activity); 

•  More  responsive  to  law,  policy,  and  social  sensitivities  as  regards 
privacy  than  has  often  historically  been  the  case  with  similar  ac¬ 
tivities; 

•  Of  streamlined/simplified  structure  from  the  point  of  view  of  indi¬ 
viduals  and  sponsors,  allowing  the  design,  development,  and  man¬ 
agement  of  standards-compliant  applications  at  lower  cost  and  with 
more  local  control  and  initiative; 

•  Designed  to  provide  convenience  and  efficiency  by  allowing  se¬ 
cure  reuse  of  credentials  in  multiple  applications. 

CHARTER: 

It  is  toward  these  ends  that  the  work  of  this  Task  Force  was  initiated,  as 
chartered  by  the  Executive  Office  of  the  President  (EOP),  National  Science  and 
Technology  Council  (NSTC),  and  Subcommittee  on  Biometrics  and  Identity 
Management. 

The  NSTC  Subcommittee  on  Biometrics  and  Identity  Management  has 
been  coordinating  interagency  biometric  efforts  since  2002.  Initial  activities  fo¬ 
cused  on  rapid  advancement  of  the  technology,  developing  standards  at  the  na¬ 
tional  and  international  level,  advancing  and  performing  evaluations,  and 
promoting  privacy  protection.  As  the  technology  advanced,  so,  too,  did  its  usage 
by  government  agencies  to  solve  important  operational  missions.  In  2006,  the 
Subcommittee  initiated  activities  to  improve  coordination  of  these  operational 
systems  and  to  jointly  determine  several  issues  that  would  serve  as  a  common 
foundation  for  agencies  as  they  began  development  of  their  next  generation  sys¬ 
tems.  It  quickly  became  clear  that  the  need  for  coordination  was  expanding  be¬ 
yond  biometrics  to  higher-level  Identity  Management  (IdM)  issues.  Once  briefed 
on  this  conclusion,  the  NSTC  Committee  on  Technology  readily  agreed  and  ex¬ 
panded  the  scope  of  the  then  biometrics-focused  Subcommittee  to  also  coordinate 
identity  management  S&T  issues.  Concurrently  with  these  discussions,  a  Defense 
Science  Board  Task  Force  was  also  studying  how  to  improve  coordination  within 
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the  Department  of  Defense.  It,  too,  reached  the  conclusion  that  successful  bio¬ 
metrics  coordination  will  require,  by  default,  coordination  on  broader  identity 
management  issues. 

In  addition  to  leading  NSTC  activities,  EOP  personnel  have  other  respon¬ 
sibilities,  such  as  reviewing  and  approving  agency  rulemaking  documents  and 
Congressional  testimony,  participating  in  policy  coordination  committees  and 
other  bodies  (such  as  the  Identity  Theft  Task  Force  and  the  Chief  Information  Of¬ 
ficer  (CIO)  Council),  and  representing  the  U.S.  in  international  technology  and 
privacy  discussions.  The  unique  across-the-government  insight  afforded  by  these 
tasks  made  it  clear  that  there  was  overlap  among  government  programs  in  IdM 
technology  and  policy  issues,  duplication  of  efforts  to  overcome  those  issues,  and 
gaps  in  required  coordination  to  enable  these  systems  to  achieve  maximum  effi¬ 
ciency  and  privacy  protection. 

In  the  summer  of  2007,  OSTP  hosted  a  small  series  of  meetings  amongst 
offices  within  the  EOP  to  discuss  IdManagement  issues.  After  some  initial  analy¬ 
sis,  the  group  agreed  that  a  more  detailed  analysis  approach  was  required.  As  a 
result,  OSTP,  in  consultation  with  other  EOP  bodies,  agreed  to  assign  this  task  to 
the  Subcommittee. 

The  Subcommittee  thus  formally  established  the  NSTC  Task  Force  on 
Identity  Management  to  assess  the  status  of  and  challenges  related  to  IdM  tech¬ 
nologies  and  develop  recommendations  regarding  federal  government’s  science 
and  technology  needs  in  this  area.  For  the  purposes  of  this  Task  Force,  Identity 
Management  means,  “The  combination  of  technical  systems,  rules  and  procedures 
that  define  the  ownership,  utilization,  and  safeguard  of  personal  identity  informa¬ 
tion.  The  primary  goal  of  the  Identity  Management  process  is  to  assign  attributes 


2  Report  of  the  Defense  Science  Board  Task  Force  on  Defense  Biometrics,  Office  of  the  Under 
Secretary’  of  Defense  for  Acquisition,  Technology  and  Logistics,  2007 
http://www.acq.osd.mil/dsb/reports/2007-03-Biometrics.pdf. 
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to  a  digital  identity  and  to  connect  that  identity  to  an  individual.”  The  tenns  of 
reference  for  this  Task  Force  are  in  Annex  A. 

1.3  SCOPE 

This  report  addresses  the  use  of  IdM  within  the  following  scope: 

•  Internal  to  the  federal  government  to  aid  in  the  performance  of 
the  full  range  of  tasks  and  missions  requiring  internal  coordination; 

•  Between  the  federal  government  and  other  governmental  ju¬ 
risdictions  (state,  local,  and  tribal); 

•  Between  the  federal  government  and  the  international  com¬ 
munity; 

•  Between  the  federal  government  and  U.S.  organizations,  com¬ 
mercial  entities,  and  individuals  accessing  government  re¬ 
sources  (both  facilities  and  systems). 

NOTE:  What  is  not  addressed  in  this  report  is  the  conduct  of  personal 
and/or  business  matters  between  and  among  citizens  and  commercial  enterprises, 
where  the  U.S.  federal  government  is  not  a  direct  party.  This  study  does  not  ad¬ 
dress  those  issues,  and  this  report  makes  no  recommendations  in  that  regard. 

1.4  STATEMENT  OF  THE  PROBLEM 

Less  than  a  decade  ago,  most  government  IT  systems  were  “stovepipes,” 
legacy  systems  developed  for  a  specific  purpose  that  did  not  interoperate  with 
other  systems  or  organizations  many  remain  so  today.  Advances  in  modem  IT 
have  made  interconnection  practical,  while  the  changing  operational  environment 
makes  expanded  interoperability  necessary,  both  from  the  standpoint  of  practical¬ 
ity  and  the  need  to  achieve  economies  of  scale  through  consolidation  and  stream¬ 
lining.  This  has  resulted  in  major  improvements  in  functionality,  as  seen  by  an 
expanded  set  of  end-users.  Today  it  takes  seconds  to  find  out  the  operating  hours 
of  government  offices  online,  a  job  that  would  have  previously  required  a  physical 
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trip,  or  at  least  a  telephone  call.  Over  the  next  decade,  these  same  systems  will 
transition  to  increasingly  complex  and  robust  digital  architecture  and  will  very 
likely  offer  more  attractive  features  at  the  same  time.  The  government  must  seek 
to  understand  the  initiative  space  available  to  enhance  the  perfonnance  of  its  di¬ 
verse  roles  and  missions.  This  will  pennit  government  to  be  as  consistent  as  pos¬ 
sible  with  the  feel  of  other  network-related  relationships  available  to  businesses 
and  citizens. 


1.5  THE  CASE  FOR  ACTION 

There  are  both  deficiencies  and  opportunities  associated  with  IdM  as  cur¬ 
rently  practiced.  These  include: 

1.5.1  Current  Deficiencies 

•  Cross-organizational  coordination.  Information  and  technical  ca¬ 
pabilities  needed  for  successful  performance  of  complex  tasks  are 
distributed  geographically  and  in  terms  of  storage  location  within 
data  networks.  They  may  also  be  under  control  of  different  or¬ 
ganizations,  which  may  employ  different  data  management  sys¬ 
tems. 

•  Disparate  security  management  protocols.  Federal  employees 
manage  numerous  credentials  (identity  cards,  user 
ID/passwords/PINs,  etc.)  for  numerous  unique  and  independent 
systems.  As  security  concerns  have  become  greater,  required  peri¬ 
odic  password  changes  and  complexity  of  password  construction 
have  all  become  more  stringent,  exacerbating  challenges  to  memo¬ 
rization  and  management. 

•  Inconsistent  Agency  Implementation.  These  make  the  emergence 
of  a  cross-domain  trust  model  difficult.  Specific  guidance  has  been 


3  It  is  important  to  note  that  the  advocated  solution  is  not  the  centralization  of  databases.  Rather, 
there  is  a  need  to  find  ways  to  enable  these  disparate  systems  to  interoperate. 


11 


provided  on  identity  assurance  trust  levels4  and  minimum  technical 
solutions  applicable  to  each  of  these  levels.5  However,  the  full  im¬ 
plementation  of  the  guidance  by  agencies  has  not  yet  been  fully  re¬ 
alized. 

•  Screening  Information  Sharing.  Many  screening  systems  are  used 
in  security  operations  to  establish  the  risk  posed  by  individuals  in 
various  contexts,  such  as  granting  visas  to  enter  the  United  States 
or  allowing  access  to  federal  govermnent  facilities.  Information  re¬ 
levant  to  these  purposes  exists  in  various  databases  held  by  various 
organizations  of  the  federal  government.  Greater  efficiencies  can 
be  gained  by  ensuring  individual  organizations  can  better  leverage 
information  across  multiple  identity  screening  databases  to  make 
accurate  assessments. 

•  Inconsistent  system-security  usages,  operating  rules  and  proce¬ 
dures.  These  pennit  the  introduction  of  vulnerabilities  into  sys¬ 
tems,  based  on  the  existence  of  these  deficiencies  in  systems  to 
which  one  is  connected.  These  “vulnerability  by  association”  risks 
invalidating  efforts  and  expenses  associated  with  systems  security. 

•  Evolving  nature  of  global  IT  grid  demands  recognition  to  preserve 
capability  and  system-wide  security.  The  total  number  of  terminal 
IT  devices  is  increasing  exponentially.  At  the  same  time,  the  per¬ 
centage  of  systems  that  are  nomadic  in  their  missions  and  wireless 
or  dynamic  in  their  physical  location  is  also  increasing.  Finally, 
there  are  clear  trends  in  the  performance  of  retail,  financial,  infor¬ 
mation,  and  other  commercial  processes  that  move  performance 
away  from  physical  hubs  toward  remote,  but  Web-accessible  ven¬ 
ues.  The  government  is  engaged  in  all  of  these  activities  and  is  af¬ 
fected  by  these  trends.  To  the  extent  that  these  evolving  IT 
architectures  represent  changes  in  the  security  system,  these  must 
be  accounted  for. 


4  OMB  Memorandum  04-04,  E -Authentication  for  Federal  Agencies. 

5  NIST  SP  800-63,  Electronic  Authentication  Guidelines. 
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•  Exploitation  of  identity  information.  If  users  can  be  deceived  into 
entering  their  PII  on  fraudulent  sites  disguised  as  real  applications, 
the  identity  thief  is  then  able  to  impersonate  the  user  to  enter  a  real 
application  and  access  all  information  and  resources  as  if  he  or  she 
were  the  genuinely  authorized  user. 

•  Interoperability  shortfalls.  Global  interoperability  will  be  achieved 
by  developing  a  bridging  function  that  enables  disparate  IdM  sys¬ 
tems  and  federations  of  systems  to  exchange  identity  information 
and  reuse  existing  credentials.  This  bridging  function  will  pennit 
individual  organizations  to  verify  identity  claims  by  querying  the 
data-stores  held  by  others.  Some  of  the  major  challenges  associated 
with  developing  standards  for  the  bridging  function  of  an  IdM 
framework  are  listed  below. 

o  Discovery  and  domain  resolution.  Discovery  is  the  process  by 
which  an  identity  provider  can  locate  the  relevant  and  authori¬ 
tative  identity  data,  which  may  be  highly  distributed  and  lo¬ 
cated  in  different  security  domains. 

o  Need  for  greater  trust.  Development  of  trust  involves  authenti¬ 
cation  by  each  of  the  parties  from  a  transaction  to  the  level  of 
assurance  required  by  the  other  party  in  order  to  proceed  with  a 
transaction.  Today,  there  are  no  globally  agreed  technical  defi¬ 
nitions  for  levels  of  trust,  nor  are  there  agreed-upon  standards 
to  measure  levels  of  trust  (i.e.,  metrics). 

o  IdM  systems  that  rely  on  loosely-coupled  identities.  When  or¬ 
ganizations  today  collaborate  with  each  other,  they  typically 
use  traditional  identity  systems  in  which  the  identifiers  are 
closely  linked  to  the  entity  being  identified.  These  may  require 
every  organization  to  have  a  local  account  for  a  user,  regardless 
of  justification.  This  collaboration,  especially  when  it  is  be¬ 
tween  changing  sets  of  partners  with  nomadic  user  populations, 
has  a  number  of  deficiencies. 

o  Lack  of  consistent  metrics.  Governmental  IdM  systems  are  not 
currently  required  to  ascertain  standard  Measures  of  Perform¬ 
ance  (MOP)  such  as  Probability  of  False  Acceptance  (PFA), 
where  a  person  is  able  to  falsely  claim  the  identity  of  another, 
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and  Probability  of  False  Rejection  (PFR),  where  a  person  is 
unable  to  claim  his/her  correct  identity.  These  and  similar 
measures  would  permit  more  nearly  direct  comparison  of  the 
performance  of  specific  systems  versus  each  other,  and/or  ac¬ 
cepted  standards. 


1.5.2  Opportunities 

This  is  where  the  full  value  of  IdM  may  be  realized.  If  approached  sys¬ 
tematically,  it  is  often  possible  to  measure  the  positive  benefits  of  IdM  in 
tangible  and  even  monetary  terms,  and  thereby  support  investment  in  spe¬ 
cific  capabilities  that  meet  return-on-investment  standards  to  justify  the  ef¬ 
fort.  Examples  include: 

•  Ability  to  capitalize  on  existing  investment  in  digital  ID  infrastruc¬ 
ture.  By  Presidential  directive,6  the  federal  government  has  estab¬ 
lished  procedures  for  the  basic  identification  of  all  federal 
employees  on  a  common  technical  standard,  called  Federal  Infor¬ 
mation  Processing  Standard  (FIPS)-201.7  This  provides  for  the 
identification  of  government  personnel  on  a  common,  interoper¬ 
able,  and  rigorous  basis,  and  the  issuance  of  a  standardized  creden¬ 
tial  attesting  to  that  identification.  However,  this  is  a  developing 
program  which  has  yet  to  realize  its  full  potential.  While  the  iden¬ 
tity  card  itself  is  gaining  broad  distribution,  the  extension  of  this 
effort  and  investment  into  application  is  currently  limited,  and  ex¬ 
isting  IT  architectures  do  not  always  support  it.  This  issue  will  be 
addressed  in  detail  below.  The  ability  to  develop  applications  that 
draw  on  the  capabilities  of  the  FIPS  201  credential  to  support  the 
whole  range  of  identity  assurance  activities,  at  much-improved 
levels  of  security  and  trust  relative  to  identity  approaches  in  com- 


6  Homeland  Security  Presidential  Directive  12  (HSPD-12),  Policy  for  a  Common  Identification 

Standard  for  Federal  Employees  and  Contractors,  2004. 
http://www.whitehoiise.gov/news/releases/2004/08/2004Q827-8.html. 

7  http://csrc.nist.gov/publications/fips 
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mon  use  elsewhere,  represents  a  great  opportunity  for  the  federal 
government. 

•  Ability  to  achieve  efficiencies  in  design  and  use  of  IT  architec¬ 
tures.  Heretofore,  IdM  systems  have  been  authorized,  designed, 
and  fielded  to  serve  specific  purposes.  In  many  cases,  the  identity- 
related  data  used  by  applications  within  the  IdM  systems  are  the 
same,  but  due  to  lack  of  good  architectural  design  for  infonnation 
sharing,  the  data  is  often  duplicated  by  the  individual  applications 
as  considered  necessary  to  support  their  particular  needs.  This 
leads  to  a  failure  to  recognize  and  update  basic  information  in  an 
equal  way,  wherever  located,  which  in  turn  gives  rise  to  confusion, 
delay,  and  error  in  practice. 

•  Ability  to  rationalize  and  harmonize  data  management  standards 
and  policies  across  historically  separate  architectures.  Interopera¬ 
bility  has  components  of  technology  and  policy.  By  seeing  the  total 
federal  IdM  activity  holistically,  common  standards  and  practices 
will  not  only  enhance  performance,  but  also  provide  more  audit- 
able  visibility  into  use  of  personal  information  of  a  private  nature. 

•  Ability  to  achieve  efficiencies  associated  with  single  sign-on  to  ac¬ 
cess  multiple  systems.  The  average  federal  employee,  in  any 
agency,  uses  numerous  IT  systems  for  various  professional  and 
administrative  purposes.  In  almost  every  case,  these  are  unique, 
stand-alone  designs  that  require  their  own  card,  key,  user 
ID/password,  or  other  form  of  log-on.  They  also  demand  different 
levels  of  trust,  based  on  the  sensitivity  of  the  application,  single  IT 
system  sign-on  at  a  high  level  of  trust  leveraging  PIV  credentials 
could  permit  federal  employees  to  establish  their  identity  at  one 
system  or  portal  and  then  access  a  wide  range  of  applications,  as 
required  to  perform  their  work  and  consistent  with  their  privileges. 


1.6  INTRODUCTION  TO  KEY  TERMS  AND  CONCEPTS 

As  discussed  above,  IdM  is  a  set  of  goals  and  concepts  currently  imple¬ 
mented  in  a  broad  and  diverse  mass  of  technology.  The  complexity  of  the  current 
legacy  architectures  and  systems  makes  any  simple  description  of  the  federal- 
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scope  IdM  system  elusive  and  necessarily  incomplete.  This  is  complicated  by  the 
fact  that  in  many  cases,  different  terms  are  used  to  describe  essentially  the  same 
processes.  This  report  will  use  several  terms  that  may  not  be  in  common  use  to¬ 
day.  In  the  interest  of  ease  of  reader  understanding,  some  of  the  most  important 
ones  are  listed  here,  as  they  will  be  used  throughout  the  report.  A  full  glossary 
may  be  found  at  Annex  K. 

Personally  Identifiable  Infonnation  —  The  foundational  issue  in  ap¬ 
proaching  any  IdM  system  is  personal  information  —  how  it  is  collected,  stored, 
shared,  and  used.  The  term  most  often  applied  to  these  data  is  “personally  identi¬ 
fiable  information”  (PII).  Generally,  PII  is  defined  as  “[t]he  infonnation  pertain¬ 
ing  to  any  person  which  makes  it  possible  to  identify  such  individual  (including 
the  information  capable  of  identifying  a  person  when  combined  with  other  infor¬ 
mation  even  if  the  infonnation  does  not  clearly  identify  the  person).”  This  may  be 
interpreted  as  “any  information  which  identifies  a  person  to  any  degree.” 

The  Task  Force  holds  that  “PII”  occupies  a  continuum  of  sensitivity  and 
that  it  assumes  a  different  character  depending  on  the  place  it  is  used  in  the  IdM 
system.  These  concepts  will  be  explained  in  greater  detail  in  section  2.4.1.  Later 
sections  of  the  report  will  introduce  structural  components  of  the  overall  federal 
IdM  system,  with  descriptions  and  relevant  terms. 

Sponsor  —  An  authority,  whether  based  in  law,  policy,  or  organiza¬ 
tional/personal  initiative,  who  seeks  to  organize  identification  infonnation  to 
regulate  the  conduct  of  some  task  or  activity,  where  not  all  persons  have  identical 
rights  or  privileges  to  perfonn  that  activity. 

Applications  —  The  ability  to  collect  or  use  identity  and  other  data  in  a 
specific  context.  Sponsors  manage  the  access  to  applications,  in  the  form  of  privi¬ 
leges  available  to  “identifiable”  persons  by  entitlement  or  enrollment.  Applica¬ 
tions  manage  and  store  transaction  and  other  specific  data  as  generated  by  an 
individual  in  their  interaction  within  the  application. 

Enrollees  —  The  persons  for  whom  digital  identities  have  been  created 
and  stored  within  an  IdM  system. 
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Beyond  these,  any  given  ID  system  may  include  identity  cards,  biometrics, 
user  ID/passwords/PINs,  and  other  unique  features.  Ideally,  these  are  selected  and 
used  as  indicated  by  the  scope,  scale,  and  nature  of  the  need  and  use,  since  these 
features  are  not  equally  attractive  in  every  ID  situation. 

This  report  seeks  to  develop  an  understanding  of  an  objective  ID  architec¬ 
ture  with  three  primary  components: 

•  Digital  Identity  Repositories; 

•  Privilege  Applications; 

•  The  Global  Telecommunications  Grid. 

Each  of  these  will  be  discussed  at  length  below.  When  these  elements  are 
assembled  into  a  system,  they  may  be  thought  of  as  relating  to  each  other  as 
shown  in  Figure  2  below.  This  simplistic  model  will  be  developed  in  greater  detail 
later  in  the  report,  but  for  now  it  serves  to  identify  and  grossly  organize  the  major 
IdM  system  components. 


The  Holistic  Vision  of  IdM 
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Figure  2.  Holistic  Vision  of  IdM 


Following  is  a  description  of  each  of  these  three  components  of  an  objec¬ 
tive  identity  architecture: 

Digital  Identity  Repositories  —  These  are  the  various  places  where  PII  is 
stored.  The  data  in  these  repositories  relate  to  individuals  in  three  major  categories 
—  Friendlies  (which  encompasses  U.S.  persons),  Adversaries  (those  known  to  be 
hostile  to  the  U.S.),  and  Unknown. 

Friendly  individuals  are  those  for  whom  information  has  been  collected  in 
order  to  facilitate  interaction.  Within  the  federal  government  scope,  these  may 
have  been  collected  and  stored  voluntarily  for  a  number  of  systems  that  perform 
services  to  various  groups  (Social  Security  services,  education  loans,  etc.). 

Alternatively,  “adversary”  data  represents  information  gathered  in  the 
conduct  of  military  or  intelligence  operations  overseas. 

Finally,  there  are  “the  unknowns”  —  persons  who  are  not  registered  in  one 
of  the  federal  government  systems  in  either  of  the  ways  discussed  above,  but  are 
not  known  to  be  hostile  to  U.S.  interests.  Data  on  individuals  in  this  category  are 
now  being  collected  under  certain  circumstances  in  support  of  national  security 
operations  and  are  retained  under  certain  circumstances  to  aid  in  coordination 
with  allies  and  identification  of  adversaries  in  the  future. 

Today,  these  repositories  containing  identity  data  associated  with  the  three 
categories  described  above  exist  in  many  different  formats,  data  standards,  and 
under  multiple  authorities.  They  each  retain  “digital  identities”  in  some  form.  The 
security  of  the  identity  data  these  repositories  contain,  in  terms  of  the  information 
assurance  technologies  and  practices  under  which  they  are  maintained,  is  cur¬ 
rently  uneven.  It  may  also  be  stated  that  the  confidence  and  trust  of  these  digital 
IDs  is  uneven,  based  on  many  factors  related  to  circumstances  of  collection,  tech¬ 
nologies,  techniques  employed,  etc. 

Privilege  Applications  —  As  noted,  a  “privilege”  is  a  grant  of  permission 
to  carry  out  a  particular  act.  In  this  context,  an  application  is  a  place  where  a  digi- 
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tal  identity  to  which  a  privilege  has  been  attached  can  achieve  some  outcome  in¬ 
volving  entitlement  to  a  resource,  information,  or  access.  For  the  most  part  the 
exercise  of  privilege  is  confined  to  individuals  in  the  “friendly”  category.  How¬ 
ever,  it  is  equally  important  to  ensure  that  individuals  in  the  “unknown”  or  “ad¬ 
versary”  categories  are  not  mistakenly  granted  privileges  reserved  for  “friendly” 
persons.  The  small  pictures  at  the  application  layer  of  Figure  2  suggest  just  a  few 
of  the  myriad  potential  functions  involving  identity  assurance  that  may  be  em¬ 
braced  within  such  a  system,  with  more  being  added  all  the  time.  As  the  diagram 
suggests,  these  applications  may  be  as  diverse  as  physical  access  to  some  location, 
the  ability  to  access  files  within  an  information  network,  or  to  support  medical  or 
military  operations.  In  fact,  the  number  and  range  of  ID  applications  is  bounded 
only  by  the  perceived  need  and  imagination  of  sponsors  who  seek  to  perfonn  their 
missions  with  efficiency  and  security. 

PII  is  contained  inside  both  the  digital  IDs  and  the  privilege  applications. 
However,  to  optimize  protections  of  privacy,  the  treatment  of  these  data  should 
differ  in  both  concept  and  practice,  as  discussed  in  detail  in  section  2.4.1. 

Global  Telecommunications  Grid  —  The  servicing  IT  grid  is  critical  in 
achieving  access,  anywhere  in  the  world,  with  continuously-available  and  inter¬ 
operable  systems  and  data  formats,  all  necessary  to  support  the  full  range  of  U.S. 
government  missions.  These  include  screening  functions,  wherein  the  objective  is 
to  determine  what  is  known  about  a  certain  person,  in  which  pursuit  applications 
may  request  access  to  multiple  other  data  stores;  and  access  controls,  which  have 
the  goal  of  facilitating  access  to  both  physical  and  online  resources,  by  persons  to 
whom  such  privileges  have  been  granted  (i.e.  friendly  individuals). 

Security  and  privacy  of  transactions  are  of  paramount  importance.  To 
achieve  these,  privacy  is  added  to  classic  information  assurance  features  of  data 
confidentiality,  authenticity,  non-repudiation,  and  integrity  as  pursued  within  gov¬ 
ernment  networks. 
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The  next  sections  will  examine  each  of  these  foundational  elements,  both  as 
they  exist  and  are  used  in  current  systems  (Section  2,  The  Current  State)  and  in 
the  objective  state  (Section  3,  The  Proposed  Framework). 
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2  THE  CURRENT  STATE 


2.1  CURRENT  FEDERAL  IDM  SYSTEM  COMPONENTS 

2.1.1  Digital  ID  Stores 

IdM  tends  to  be  approached  with  targeted  solutions  to  meet  specific  and 
internally-defined  agency  needs.  While  this  strategy  may  be  effective  at  solving 
narrowly  scoped  problems,  it  has  led  to  the  growth  of  “stovepiped”  legacy  sys¬ 
tems  in  complex  and  non-interoperable  configurations.  These  patchwork  architec¬ 
tures  inhibit  cooperation  and  hinder  the  efficient  delivery  of  government  services 
across  the  spectrum  of  stakeholders.  To  a  certain  extent,  this  situation  arises  from 
some  of  the  essential  characteristics  of  government  as  an  organization.  It  is  natural 
for  applications  and  infonnation  stores  to  become  isolated  in  an  environment 
where: 

•  Innovation  and  change  may  be  valued  less  than  stability,  continu¬ 
ity,  and  predictability; 

•  Inter-departmental  boundaries  are  fixed  and  stakeholder  boundary 
crossing  is  discouraged; 

•  Policy  changes  may  drive  systems  redesign  or  reconfigure  their 
uses; 

•  Agency  initiatives  may  conflict  or  overlap;  and 

•  The  scope  of  activities  can  be  expansive  and  at  times  unrealistic.8 

This  is  the  current  situation  in  IdM,  which  leads  to  duplicative  identity  da¬ 
ta  often  being  stored  in  multiple  locations  within  the  same  agency,  e.g.,  once  for 


Sundberg  &  Sandberg,  2006 
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human  resources  and  once  for  the  employee  phone  directory.  The  data  may  also 
be  duplicated  for  procedural  reasons.  For  example,  different  operating  divisions 
within  the  same  agency  will  often  not  share  identity  information  about  transferred 
employees  due  to  questions  over  whose  budget  will  be  charged  for  collecting  and 
managing  the  data.  This  results  in  both  divisions  collecting,  retaining,  and  paying 
for  the  same  information.  These  issues  exemplify  the  challenges  that  must  be 
faced  in  aiming  for  interagency  identity  data  sharing. 

As  the  federal  government  has  sought  to  align  its  processes  more  effec¬ 
tively  and  to  become  more  businesslike  some  of  these  obstructive  traits  have  be¬ 
gun  to  recede  in  prominence.  At  the  same  time,  legacy  and  fragmented  system 
solutions  remain,  including  those  that  perform  IdM  functions. 

Another  area  of  critical  importance  to  IdM  generally  is  that  of  standards. 
This  subject  is  addressed  in  more  depth  below,  but  as  specifically  related  to  digital 
ID  stores,  the  lack  of  government-wide  standardization  in  the  use  of  existing  data 
elements  across  the  federal  government  has  significantly  contributed  to  slow  pro¬ 
gress  and  low  levels  of  adoption.9  Work  has  been  done  in  some  important  aspects 
of  IdM  standards,  notably  in  biometrics.  However,  there  is  still  much  work  to  be 
accomplished  to  standardize  all  aspects  of  identity  data  storage  and  use. 

The  problems  attendant  to  this  lack  of  standards  are  amplified  in  screening 
processes,  where  information  derived  from  intelligence,  law  enforcement,  or  even 
foreign  sources  may  use  various  transliteration,  spelling,  or  usage  conventions. 
The  possibility  that  such  data  may  represent  aliases,  and  as  such  are  inherently 
unreliable,  cannot  be  discounted.  Even  so,  the  basic  issues  remain  —  when  such 
data,  however  fragmentary  and  unreliable,  are  collected,  stored,  and  managed  in 


9  The  need  for  standards  has  been  identified  as  a  key  IdM  enabler  (NECCC,  2002). 
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separate  “stovepiped”  systems.  Any  judgments  or  new  information  regarding  the 
underlying  individual  that  precipitate  changes  to  the  data  set  must  be  duplicated 
identically  wherever  the  data  are  held,  or  else  the  records  will  diverge.  Over  time, 
one  person  may  appear  as  two  or  more  digital  identities,  each  appearing  to  repre¬ 
sent  a  different  individual,  increasing  the  chances  of  misidcntilication. 

An  identity  landscape  characterized  by  similar  but  unconnected  islands  of 
data  in  non-standard  forms  raises  significant  hurdles  in  many  data  management 
areas:  information  assurance,  data  quality,  privacy  protection,  security,  and  re¬ 
source  allocation.  In  this  environment,  risks  are  manifold  and  likely  unknowable 
in  their  entirety.  These  are  risks  not  only  to  government  itself,  but  to  the  people  it 
serves.  As  noted,  dependency  on  IdM-based  processes  to  perform  increasingly 
broad,  and  increasingly  important,  governmental  functions  is  an  accelerating 
trend.  Thus,  insecurity  in  this  area  places  increasingly-critical  outcomes  at  risk, 
including  those  associated  with  national  security. 


2.1.2  Global  Telecommunications  Grid 

The  Global  Telecommunication  Grid  (GTG)  consists  of  the  public- 
switched  telecommunications  network  (PSTN),  various  forms  of  Internet  protocol 
(IP)  networks  including  the  current  Internet,  managed  Enterprise  Networks  and 
other  IP  networks  (e.g.,  converged  services),  and  “cable”  networks.  It  is  the  means 
to  collaborate,  share  information,  and  achieve  and  maintain  infonnation  security. 

This  network  of  networks  can  be  viewed  horizontally  as  a  system  of  inter¬ 
operable,  or  at  least  interworking,  transport  networks,  and  also  can  be  viewed  ver¬ 
tically  as  a  system  of  widely  differing  application  services  riding  on  the  transport 
networks.  Identity  services  are  supported  by  a  heterogeneous  collection  of  provid¬ 
ers  (some  of  which  may  also  be  transported  to  network  providers)  to  a  large 
community  of  nomadic  users  and  access  devices  over  a  wide  range  of  access 
technologies.  The  GTG  is  notional,  and  its  implementation  is  uneven  both  geo¬ 
graphically  and  technically.  The  interworking  bridging  functions,  those  that  en- 
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able  disparate  systems  to  exchange  identity  information  and  reuse  existing  creden¬ 
tials,  between  all  the  networks  and  services  have  not  been  completely  addressed, 
particularly  in  IdM. 

Within  the  government,  the  Department  of  Defense  (DOD)  has  long 
sought  to  define,  build,  and  manage  a  set  of  services  as  needed  to  support  its 
unique  global  mission  needs.  This  is  called  the  Global  Information  Grid  (GIG) 
and  is  discussed  in  some  detail  in  Annex  D. 

Historically,  the  information  and  technology-support  systems  of  the  vari¬ 
ous  departments  and  agencies  of  the  federal  government  were  not  designed  or 
built  to  be  interoperable.  Security  concerns  associated  with  sharing  data,  incre¬ 
mental  costs  involved  in  engineering  the  systems  to  work  together,  and,  as  noted, 
the  general  absence  of  broadly-scoped  technology  standardization,  all  served  to 
inhibit  interoperability.  Until  quite  recently,  interoperability  across  organizations 
has  been  dealt  with  on  a  case-by-case  basis. 

The  growing  sense  of  need  for  collaboration  between  and  among  persons 
and  entities  which  are  geographically  and  organizationally  distributed  has  paral¬ 
leled  the  emergence  of  the  technical  means  to  achieve  such  collaboration.  In  doing 
so,  it  has  become  increasingly  important  to  positively  establish  the  identity  of  the 
IT  systems  —  and  their  operators  —  involved  in  such  interaction.  As  will  be  dis¬ 
cussed  below,  this  has  influenced  the  direction  of  advanced  technical  standards 
efforts,  including  those  focused  on  identifiability  of  systems  components,  as  well 
as  more  traditional  human  areas,  such  as  biometrics. 

2.1.3  Applications 

The  Task  Force  desired  to  better  understand  how  digital  identities  are  be¬ 
ing  applied  in  programs  within  and  across  the  federal  government,  and  toward 
that  end,  conducted  a  two-part  analysis:  Review  of  Privacy  Impact  Assessment 
(PIA)  documents,  as  filed  for  existing  federal  programs;  and  a  survey  of  federal 
Chief  Information  Officers,  via  a  detailed  questionnaire  circulated  to  members  of 
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the  federal  CIO  Council.  Detailed  discussion  of  these  efforts  and  their  findings  is 
found  in  Annexes  G  (data  calls)  and  H  (PIA  analysis),  respectively. 


2.2  THE  INTERNATIONAL  ENVIRONMENT 

A  major  difference  between  the  international  environment  and  the  domes¬ 
tic  federal  environment  is  that  in  the  global  context  there  is  no  overall  governing 
body  that  has  the  authority  to  impose  a  consistent  IdM  organizational  concept  on 
the  wide  variety  of  IdM  organizations.  Instead,  interworking  and  interoperability 
between  disparate  IdM  concepts  and  systems  is  achieved  through  consensus  that 
is  ultimately  negotiated  in  international  standards-setting  organizations.  The  de¬ 
velopment  and  eventual  global  adoption  of  technical  standards  as  needed  to  sup¬ 
port  IdM  processes  on  interconnected  IT  networks  is  in  the  critical  path  to 
achieving  the  values  and  potential  benefits  envisioned  here. 

Within  the  federal  interagency  process,  the  State  Department  coordinates 
U.S.  positions  on  IdM  that  relate  to  bodies  created  or  chartered  by  governmental 
organizations.  The  most  notable  among  these  are  the  International  Telecommuni¬ 
cation  Union  (ITU),  the  International  Organization  for  Standardization  (ISO),  and 
the  Organization  for  Economic  Co-operation  and  Development  (OECD),  inter 
alia.  More  detailed  discussion  of  these  groups  and  their  efforts  may  be  found  at 
Annex  J.  Typically,  U.S.  delegations  to  standards  fora  include  representatives 
from  other  interested  federal  agencies,  as  well  as  representatives  from  the  private 
sector.  Other  standards  work  is  conducted  under  auspices  of  international  trade 
associations  and  various  federal  organizations  serve  as  sponsoring  coordinators. 


2.3  IDENTITY  MANAGEMENT  AND  CYBERSECURITY 

From  the  point  of  view  of  the  U.S.  government,  the  pacing  factor  in  the 
emergence  of  globally  interworking  international  IT  systems  is  the  emergence  and 
adoption  of  standards-based  architectures  that  support  the  full  range  of  govern¬ 
ment  missions,  functions,  and  professional  concerns.  These  include  the  ability  to 
identify  systems,  data,  and  individuals  participating  in  the  network,  and  related  to 
that,  the  full  range  of  cyber  security  issues.  While  a  detailed  discussion  of  the  lat- 
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ter  topic  exceeds  the  scope  of  this  paper,  there  are  certain  areas  of  clear  overlap 
between  cyber  security,  writ  large,  and  IdM.  These  are  briefly  addressed  in  Sec¬ 
tion  5.2.2. 


2.4  REQUIREMENTS 

Specific  recommendations  will  be  provided  later  in  the  report.  This  section 
addresses  the  top-level  considerations  upon  which  any  successful  IdM  system  — 
and  most  especially  those  of  the  proposed  future  state  —  must  be  predicated. 

2.4.1  Privacy 

Today’s  key  privacy  issues  focus  on  managing  and  protecting  information 
about  individuals,  as  well  as  maintaining  the  public’s  trust  and  confidence  in  the 
U.S.  government.  Informational  privacy  deals  with  the  rights  of  an  individual  as  it 
relates  to  information  collected  about  them,  nformation  privacy  analysis  usually 
focuses  on  technology  —  how  a  particular  type  or  implementation  of  information 
technology  affects  the  information  privacy  interests  of  those  affected.  In  their  in¬ 
fluential  1890  article  on  the  subject  of  privacy,  “The  Right  to  Privacy,”  Samuel 
Warren  and  Louis  Brandeis  focused  on  the  then-emerging  technology  of  handheld 
photography  and  how  the  instantaneous  collection  of  infonnation  about  individu¬ 
als  without  their  consent  affected  their  right  to  privacy.  The  same  concern  raised 
in  1890  about  photography  continues  to  apply  today  to  the  federal  government’s 
use  of  IdM  technology. 

2. 4. 1.1  Privacy  Requirements 

The  chief  statutory  privacy  protection  for  personal  infonnation  held  by  the 
U.S.  government  is  the  Privacy  Act  of  1974.  The  Privacy  Act  applies  to  certain 
records  about  United  States  citizens  and  aliens  lawfully  admitted  for  pennanent 
residence.  The  records  must  be  contained  within  a  “System  of  Records,”  which  is 
defined  as  “a  group  of  any  records  under  the  control  of  any  agency  from  which 
information  is  retrieved  by  the  name  of  the  individual  or  by  some  identifying 
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number,  symbol,  or  other  identifying  particular  assigned  to  the  individual.”  5 
U.S.C.  §  552a(a)(5). 

Additionally,  the  statute  defines  a  “record”  as  “any  item,  collection,  or 
grouping  of  infonnation  about  an  individual  that  is  maintained  by  an  agency,  in¬ 
cluding,  but  not  limited  to,  his  education,  financial  transactions,  medical  history, 
and  criminal  or  employment  history,  and  that  contains  his  name  or  the  identifying 
number,  symbol,  or  other  identifying  particular  assigned  to  the  individual,  such  as 
a  finger  or  voice  print  or  a  photograph.”  5  U.S.C.  §  552a(a)(4). 

The  Privacy  Act  imposes  a  number  of  requirements  on  the  agency  holding 
the  records  and  provides  a  number  of  rights  to  the  individuals  whose  records  are 
being  kept. 

These  are  examples  of  certain  Privacy  Act  requirements  and  rights  that 
will  impact  IdM  systems: 

•  There  is  a  general  prohibition  on  the  disclosure  of  Privacy  Act  re¬ 
cords  without  consent,  with  certain  exceptions.10 

•  Agencies  must  publish  notices  in  the  Federal  Register  describing 
their  Systems  of  Records. 

•  Agencies  must  maintain  information  that  is  accurate,  relevant, 
timely,  and  complete,  while  keeping  administrative  safeguards  on 
their  System  of  Records.11 


10  Exceptions  include  disclosures  within  an  agency  to  those  with  a  “need  to  know,”  pursuant  to  a 

published  routine  use,  at  the  request  of  the  head  of  a  law  enforcement  agency,  for  the  health  or 
safety  of  an  individual,  and  pursuant  to  a  court  order.  See  5  U.S.C.  §  552a  (b)(l)-(12)  (2006). 

1 1  Agencies  may  exempt  certain  systems  of  records  from  some  of  the  Privacy  Act’s  provisions.  See 

5  U.S.C.  §  552a(j)  and  (k). 
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•  With  certain  exceptions,  individuals  have  the  right  to  access  to  Pri¬ 
vacy  Act  records  about  themselves  and  the  right  to  request  correc¬ 
tion  of  Privacy  Act  records  about  themselves. 

•  Individuals  also  have  a  right  to  file  a  lawsuit  in  federal  district 
court  to  enforce  the  obligations  of  agencies  mentioned  in  the  above 
paragraph. 

The  second  major  statutory  privacy  authority  is  the  E-Government  Act  of 
2002.  It  also  affords  privacy  protections  for  individuals  with  respect  to  IdM  sys¬ 
tems.  Section  208  of  the  Act  requires  a  Privacy  Impact  Assessment  (PIA)  to  be 
completed  by  the  agency  for  most  information  technology  systems  that  collect, 
maintain,  or  disseminate  PII.  PII  is  defined  by  the  Office  of  Management  and 
Budget  as: 


“Information  which  can  be  used  to  distinguish  or  trace  an  individ¬ 
ual’s  identity,  such  as  their  name,  Social  Security  number,  biomet¬ 
ric  record,  etc.  alone,  or  when  combined  with  other  personal  or 
identifying  infonnation  which  is  linked  or  linkable  to  a  specific  in¬ 
dividual,  such  as  data  and  place  of  birth,  mother’s  maiden  name, 
etc.”13 

A  PIA  is  required  to  analyze  seven  factors: 

1 .  What  infonnation  is  to  be  collected; 

2.  Why  the  information  is  being  collected; 

3.  The  intended  use  of  the  information; 


2  One  exception  to  this  requirement  is  for  national  security  systems.  The  E-Govemment  Act  does 
not  require  PIAs  for  national  security  systems  as  defined  by  section  11103  of  title  40,  United 
States  Code. 

13  Office  of  Management  and  Budget  Memorandum  for  the  Heads  of  Executive  Departments  and 
Agencies,  M-07-16,  “Safeguarding  Against  and  Responding  to  the  Breach  of  Personally  Iden¬ 
tifiable  Information,”  May  22,  2007,  Page  1,  FN  1. 
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4.  With  whom  the  information  will  be  shared; 

5.  What  opportunities  individuals  have  to  decline  to  provide  information 
or  to  consent  to  particular  uses  of  the  information; 

6.  How  the  information  is  secured; 

7.  Whether  a  System  of  Records  is  being  created  under  the  Privacy  Act. 

Agencies  are  required  to  publish  completed  PI  As  on  public  Web  sites  to 
allow  for  transparency  to  the  public  about  their  collections  of  PII  technology  sys- 

14 

terns. 


Underlying  the  application  of  the  privacy  requirements  of  both  the  Privacy 
Act  and  the  E-Government  Act  is  a  set  of  guiding  principles,  also  referred  to  as 
“Fair  Infonnation  Practice  Principles”  or  “FIPPs.”15  These  principles  derive  from 
the  1973  HEW  Report,16  which  described  them  as  follows: 

•  There  must  be  no  personal  data  record-keeping  systems  whose 
very  existence  is  secret. 

•  There  must  be  a  way  for  a  person  to  find  out  what  information 
about  the  person  is  in  a  record  and  how  it  is  used. 


14  The  E-Government  Act  does  not  require  the  publication  of  PIAs  containing  sensitive,  classified, 

or  private  information. 

15  The  Federal  Trade  Commission  provides  a  general  overview  of  these  principles  on  their  Web 

site,  www.ftc.gov,  direct  URL:  http://www.ftc.gov/reports/privacy3/fairinfo.shtm. 

16  "Elliott  Richardson,  then  Secretary  of  Health,  Education  and  Welfare,  named  an  Advisory 

Committee  on  Automated  Personal  Data  Systems  to  make  an  intensive  study  of  the  impact  of 
computer  data  banks  on  individual  privacy.  Its  detailed  report,  “Records,  Computers,  and  the 
Rights  of  Citizens,”  was  published  in  1973  and  recommended  the  enactment  of  federal  legis¬ 
lation  guaranteeing  to  all  Americans  a  “code  of  fair  information  practices.”  H.R.  16373  [the 
bill  that  became  the  Privacy  Act]  embodies  the  major  principles  of  these  recommendations  as 
they  apply  to  an  individual's  access  to  records  in  the  federal  government."  H.R.  Rep.  No.  93- 
1416,  at  7  (1974). 
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•  There  must  be  a  way  for  a  person  to  prevent  infonnation  about  the 
person  that  was  obtained  for  one  purpose  from  being  used  or  made 
available  for  other  purposes  without  the  person’s  consent. 

•  There  must  be  a  way  for  a  person  to  correct  or  amend  a  record  of 
identifiable  information  about  the  person. 

•  Any  organization  creating,  maintaining,  using,  or  disseminating  re¬ 
cords  of  identifiable  personal  data  must  assure  the  reliability  of  that 
data  for  their  intended  use  and  must  take  precautions  to  prevent 
misuses  of  the  data. 

In  1980,  the  Organization  for  Economic  Co-operation  and  Development 
(OECD)  adopted  Guidelines  on  the  Protection  of  Privacy  and  Transborder  Flows 
of  Personal  Data,  which  provide  a  framework  for  privacy  that  has  been  referenced 
in  U.S.  federal  guidance  and  internationally.  The  OECD  Guidelines  present  a  sim¬ 
ilar  set  of  principles  in  Collection  Limitation,  Data  Quality,  Use  Limitation,  Secu¬ 
rity  Safeguards,  Openness,  Individual  Participation,  and  Accountability.17 

Application  of  these  principles  requires  identification  of  information  that 
relates  to  individuals  and  then  assessment  of  how  privacy  protections  should  be 
applied  to  the  use  of  that  information.  While  the  Privacy  Act  does  not  identify 
technology  specifically  as  the  primary  area  of  concern  the  way  the  E-Government 
Act  does,  the  IT-centric  nature  of  today’s  business  and  government  operations 
means  that  the  majority  of  the  time,  the  privacy  analysis  will  start  with  this  con¬ 
sistent  foundation:  an  understanding  of  what  infonnation  is  connected  with  a  par¬ 
ticular  type  of  technology  or  IT  system,  how  that  technology  uses  the  infonnation, 
the  individuals  who  may  be  affected  by  that  particular  use,  and  the  methods  used 
to  protect  privacy.  This  analysis  is  driven  by  a  detennination  of  how  information 
and  technology  are  managed  in  a  particular  technology  environment.  Thus,  in  or- 


17  The  OECD  principles  are  available  on  the  OECD  Web  site:  www.oecd.org.  (direct  URL: 
http://www.oecd.Org/document/18/0.2340.en  2649  34255  1815186  111  1.00.html). 


30 


der  to  assess  the  privacy  implications  of  IdM,  one  must  first  determine  how  in¬ 
formation  related  to  individuals  is  used  in  an  identity  management  environment. 

The  next  step  is  to  detennine  how  infonnation  in  general  is  used  in  an  IdM 
environment.  The  final  step  is  to  determine  the  implications  of  how  PII  is  used  in 
an  IdM  environment  and  the  privacy  considerations  that  should  be  addressed 
when  deploying  IdM. 

2. 4. 1.2  Identity  Management  Environment 

The  IdM  goal  is  to  manage  information  related  to  an  identity,  as  part  of  a 
process  such  as  screening  or  access  control, to  manage  activities  within  the  appli¬ 
cation  that  relate  to  that  individual,  while  seeking  to  keep  the  data  relating  to  them 
separate.  The  privacy  goal  is  to  ensure  that  PII  is  used  in  a  controlled,  purposeful, 
and  lawful  manner  and  in  a  way  that  minimizes  the  impact  on  an  individual.  To 
achieve  both  the  IdM  and  privacy  goals,  one  must  first  find  a  common  element, 
something  that  is  referenced  by  both  the  IdM  technology  and  privacy  policy.  That 
common  element  is  information  —  attribute  information,  specifically.  Attribute 
information  are  characteristics  or  elements  of  information  that  describe  their  sub¬ 
ject.  For  example,  an  attribute  of  a  person  might  be  height  or  hair  color.  Another 
attribute  of  a  person  might  be  an  assigned  number  like  a  Social  Security  number. 
Other  attributes  related  to  a  person  might  be  infonnation  about  a  person’s  activi¬ 
ties,  such  as  when  a  person  applied  for  a  federally  issued  identification  card. 
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The  Continuum  of 
Personally-ldentifiable  information 


Figure  3.  The  Continuum  of  Personally  Identifiable  Information 


Structurally,  IdM  can  be  viewed  as  the  interaction  of  two  sets  of  attributes, 
attributes  about  activities  (“activity  attributes”)  and  attributes  about  the  identity  of 
an  individual  (“identity  attributes”)  —  managed  by  a  control  gate  that  associates 
identity  attributes  with  activity  attributes  and  enables  applications  to  use  identity 
information  from  remote  sources.  By  viewing  all  the  information  in  an  IdM  envi¬ 
ronment  as  attributes,  one  can  more  easily  determine  what  identity  attributes  are 
required  to  support  access  to  which  activities  within  the  application  and  then  limit 
the  use  of  identity  attributes  to  only  those  that  are  required. 

From  a  privacy  perspective,  all  attributes  should  be  considered  PII  and  are 
differentiated  by  their  location  on  the  continuum  of  privacy  sensitivity.  It  is  im¬ 
possible  to  gather  enough  information  about  a  person  to  equal  that  person’s  entire 
“identity.”  Instead,  there  is  a  continuum  of  identity  attributes  that  can  be  used  ei- 
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ther  individually  or  in  combination  to  point  toward  a  single  person  as  precisely  as 
necessary.  The  greater  the  precision  of  the  attributes,  the  more  privacy-sensitive 
the  attribute  information  becomes  and  the  greater  the  privacy  concern. 

Because  IdM  will,  by  definition,  use  some  identity  attributes,  there  will 
always  be  some  level  of  privacy  concern.  The  issue  will  be  the  level  of  the  con¬ 
cern  based  on  risks  to  the  individual  and  the  organization.  The  more  uniquely  the 
attribute(s)  identifies  a  person,  or  the  more  personal  the  quality  of  that  attribute  is 

(evaluated  by  the  level  of  concern  a  person  might  have  if  that  particular  attribute 

1  8 

were  to  be  linked  to  that  individual),  the  greater  the  potential  privacy  risk.  The 
greater  the  potential  privacy  risk,  the  more  detailed  the  privacy  analysis  must  be, 
and  the  greater  the  importance  of  privacy  risk  mitigations. 

In  addition  to  the  privacy  interest  in  identity  attributes,  there  are  also  pri¬ 
vacy  interests  in  the  activity  attributes.  In  situations  where  an  access  decision  is 
required,  the  application  itself  will  use  the  identity  information  to  grant  access  to 
specific  activities  and  through  that  association,  more  characteristics  of  the  indi¬ 
vidual  could  be  created.  For  example,  if  the  application  tracks  access  to  a  sensi¬ 
tive  government  computer  system,  the  record  of  gaining  access  to  the  system 
could  also  be  a  descriptive  attribute  of  the  individual  associated  with  that  granting 
of  access.  Here  again,  from  the  privacy  perspective,  there  is  a  continuum  of  pri¬ 
vacy  sensitivity.  Some  activity  infonnation  may  be  less  privacy  sensitive  than  oth¬ 
ers.  When  conducting  the  privacy  impact  assessment,  however,  one  should  always 
be  sensitive  to  the  context  in  which  the  infonnation  is  used.  Certain  associations 
of  identity  and  activity  attributes  may  become  more  privacy  sensitive  based  on  the 
decisions  about  the  individual  that  would  be  drawn  from  that  combined  informa¬ 
tion.  In  determining  which  attributes  within  an  IdM  implementation  should  be 
considered  sensitive,  both  types  of  attributes,  identity  and  activity,  should  be  re¬ 
viewed,  and  impact  on  the  individual  from  the  use  of  that  PII  should  be  evaluated 
within  the  specific  context  of  the  decisions  made  about  that  individual. 


18  In  additional  to  specificity,  other  factors  for  determining  sensitivity  may  include  context  of  use, 
legal  obligations,  and  combinations  of  different  types  and  amounts  PII. 
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The  privacy  analysis  must  address  the  full  data  life  cycle  —  all  uses  of  all 
the  data  by  all  the  parties,  over  time  —  meaning  that  any  activity  data  going  back 
to  the  “source”  of  the  identity  attributes  should  be  reviewed  from  the  perspective 
of  the  organization  providing  the  original  identity  attributes.  It  is  possible  that 
enough  activity  information  could  be  sent  back  to  the  identity  provider  to  give 
more  information  about  the  individual  than  was  contained  originally  in  the  set  of 
identity  attributes.  Any  information  that  is  used  for  the  purpose  of  identifying  and 
describing  an  individual  should  be  considered  PII  and  included  in  the  privacy  as¬ 
sessment. 

The  privacy  impact  of  a  particular  attribute  or  a  particular  combination  of 
attributes  will  always  be  context  specific.  Each  use  of  each  attribute  that  is  linked 
or  linkable  to  an  individual  should  be  reviewed  to  determine  whether  it  is  required 
to  meet  the  specific  needs  of  the  application.  Once  that  determination  is  made, 
specific  privacy  protections  can  be  implemented  to  ensure  that  only  those  attrib¬ 
utes  are  used  and  that  they  are  used  only  for  the  specified  purpose  (that  is,  no  ad¬ 
ditional  infonnation  about  the  individual  could  be  drawn  from  particular  attributes 
information  —  both  identity  and  application  —  that  might  extend  beyond  the 
original  intended  use). 

Another  key  to  a  well-implemented  IdM  environment  is  a  reliable  trust 
model  that  enables  the  application  to  rely  on  the  identity  assertions  of  the  identity 
provider.  To  prevent  each  application  from  establishing  its  own  “identity”  for  the 
individual,  applications  must  be  able  to  trust  the  identity  information  they  get 
from  an  identity  provider.  This  trust  makes  it  possible  to  isolate  the  specific  iden¬ 
tity  attributes  that  are  needed  for  the  specific  functions  of  the  application.  The  in¬ 
frastructure  on  which  the  trust  model  is  based  can  then  be  relied  on  to  support 
privacy  protections  to  show  that  only  specific  attributes  were  used  by  specific  ap¬ 
plications  for  specific  needs. 
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2. 4. 1.3  Privacy  Protections 


In  any  IdM  implementation,  and  particularly  as  the  use  of  IdM  expands 
and  more  government  services  are  managed  electronically,  fundamental  privacy 
concerns  must  be  addressed.19  These  include: 

•  Ensuring  that  the  IdM-based  service  is  designed  with  flexibility 
and  implemented  well  to  accommodate  potential  IdM  changes.  The 
design  should  operate  the  way  it  is  described  and  improve  security 
and  delivery  of  the  service  without  creating  additional  burdens. 

•  Supporting  individuals  who  are  not  “in  the  system”  due  to  financial 
status,  difficulty  gaining  access,  and  other  reasons.  As  “identifica¬ 
tion”  becomes  an  increasingly  electronic  activity,  emerging  IdM 
systems  might  disenfranchise  individuals  that  lack  reliable  elec¬ 
tronic  “attribute”  information  because  they  might  lose  the  ability  to 
participate  in  specific  applications  that  functioned  properly  when 
relying  less  on  electronic  identification.  Examples  include  victims 
of  identity  theft,  for  whom  the  identity  attributes  may  exist  inaccu¬ 
rately  because  they  no  longer  point  to  the  individual  actually  en¬ 
gaged  in  a  particular  activity.  Avoiding  the  exclusion  of  such 

20 

individuals  is  a  fundamental  necessity  for  an  equitable  system." 

•  Upholding  the  accuracy  of  the  data  used  by  an  IdM  system  is  pa¬ 
ramount,  especially  if  matching  programs  compare  data  between 
IdM  systems  to  verify  user  information.  As  a  general  matter,  when 
PII  is  collected  from  the  individual,  the  probability  that  the  infor¬ 
mation  is  accurate  is  higher  than  when  that  same  infonnation  is 
collected  from  a  third-party  source. 


19  For  an  in  depth  discussion  of  privacy  issues  related  to  identity  systems,  see:  Peter  P.  Swire  and 

Cassandra  Q.  Butts,  “The  ID  Divide,”  Center  for  American  Progress, 
www.americanprogress.org,  June  2008. 

20  Ibid. 
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•  Allowing  individuals  to  maintain  control  of  PII  through  user¬ 
centric  IdM  systems.  If  individuals  insert  PII  directly  into  the  IdM 
system,  they  may  trust  the  operation  of  the  system  more  because 
they  know  the  nature  and  source  of  the  infonnation  the  IdM  system 
is  using  to  establish  their  access. 

•  Securing  the  core  identifying  attributes  through  encryption  stan¬ 
dards  and  privacy-enhancing  technologies.  When  IdM  systems  rely 
on  a  set  of  core  identity  attributes,  that  core  identity  infonnation 
must  be  secured  to  the  greatest  extent  possible.  This  requirement 
applies  to  all  PII,  particularly  when  PII  cannot  be  replaced  easily, 
as  is  the  case  with  biometrics.  If  PII  is  lost  or  otherwise  compro¬ 
mised,  established  policies  and  procedures  should  ensure  that  data 
breaches  are  reported  quickly  and  investigated  thoroughly,  and  the 
affected  individuals  should  receive  assistance. 

•  Designing  IdM  systems  based  on  open  standards,  using  a  flexible 
and  interoperable  infrastructure  that  spans  numerous  access  de¬ 
vices  and  platforms.  Such  standards  should  support  auditing  by  in¬ 
dividuals  and  system  administrators,  encouraging  consistent  and 
shared  responsibility  to  maintain  accuracy  and  relevance  of  the  in¬ 
formation  pertaining  to  the  individuals. 

•  Preventing  the  identity  attribute  information  from  being  used  for 
purposes  beyond  those  for  which  it  was  collected  by  using  ma¬ 
chine-readable  policies  that  remain  with  individual  PII  attributes 
for  the  lifetime  of  those  data  to  regulate  access.  Such  measures 
hinder  unauthorized  use,  and  they  could  possibly  send  notification 
alerts  to  users  and  administrators  of  potentially  fraudulent  or  inap¬ 
propriate  activity,  much  as  credit  file  monitoring  functions.  In  ad¬ 
dition,  these  measures  can  deter  possible  “mission  creep”  within  a 
particular  system. 

•  Enabling  individuals  to  access  and  correct  information  easily  and 
verifiably  in  cases  of  identification  errors  within  the  IdM  system.  If 
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individuals  cannot  fix  errors  conveniently  and  directly,  the  respon¬ 
sible  agency/organization  should  provide  a  simple,  effective,  and 
verifiable  mechanism  for  the  individual  to  seek  redress.  The  more 
privacy-sensitive  the  information  in  the  IdM  system,  the  more  im¬ 
portant  these  additional  requirements  become. 

•  Implementing  privacy  protections  into  the  system  so  they  are  au¬ 
tomated  as  much  as  possible  but  can  be  adjusted  to  accommodate 
new  privacy  requirements,  as  needed.  Today,  much  of  the  privacy 
policy  enforcement  is  accomplished  through  traditional  methods, 
such  as  written  policies  and  procedures  given  to  system  users  to 
follow  as  they  see  fit.  In  the  future,  building  protections  directly  in¬ 
to  the  technology  will  provide  greater  assurance  that  the  protec¬ 
tions  are  implemented  thoroughly  and  consistently.  That  being 
said,  there  should  always  be  a  human-driven  recourse  to  override 
the  system  when  needed. 

•  Designing  privacy  training  into  the  design  and  operation  of  IdM 
systems  so  system  developers  and  users  understand  the  responsi¬ 
bilities  attached  to  using  PII.  OMB  Memorandum  07-16,  Safe¬ 
guarding  Against  the  Breach  of  Personally  Identifiable 
Information,  provides  specific  guidance  concerning  the  training  of 
employees  (including  managers)  on  their  privacy  and  security  re¬ 
sponsibilities  before  pennitting  access  to  agency  information  and 
information  systems. 

•  Removing  PII  when  it  is  no  longer  needed.  Retaining  PII  unneces¬ 
sarily  creates  privacy  risks.  It  should  be  noted  that  law  enforce¬ 
ment  and  homeland  security  needs  may  require  personally 
identifiable  information  to  be  held  for  investigative  or  screening 
purposes  for  long  periods  of  time. 

IdM,  as  with  all  emergent  and  evolving  technology,  will  continue  to  pre¬ 
sent  challenges  to  government  and  society  to  provide  opportunities  to  reexamine 
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fundamental  principles,  perspectives,  and  specific  practices  in  new  contexts.  This 
point  is  constantly  reemphasized  over  time,  as  public  attitudes  regarding  a  given 
program,  technology,  or  process  evolves.  These  attitudes  will  be  heavily  influ¬ 
enced  by  recognition  of  value  and  benefit,  ideally  packaged  with  convenience. 
Successful  implementation  of  IdM  for  access  control  purposes  should  deliver  real 
value  directly  to  the  individual  including  increased  access  to  an  expanded  set  of 
services,  improved  timeliness  of  service,  reduced  risk  of  fraud  or  error  in  the  con¬ 
duct  of  business  with  the  government,  and  reduced  risk  of  identity  theft.  The 
value  and  benefit  of  IdM  will  be  enhanced  by  ensuring  that  privacy  concerns  are 
recognized  and  appropriate  privacy  protections  are  built  into  an  IT  system  which 
uses  IdM. 

2.4.2  Policy/Authority 

In  addition  to  the  laws  discussed  above,  there  are  other  authorities  that  al¬ 
so  impact  on  the  privacy  and  security  of  IdM  systems.  These  include  presidential 
directives,  federal  law,  and  Office  of  Management  and  Budget  (OMB)  guidelines. 
Among  the  former  are: 

HSPD-6,  Integration  and  Use  of  Screening  Information,  was  signed  by  the 
President  in  2003.  It  seeks  to  “develop,  integrate,  and  maintain  thorough  accurate 
and  current  infonnation  about  individuals  known  or  appropriately  suspected  to  be 
or  have  been  engaged  in  conduct  constituting,  in  preparation  for,  in  aid  of,  or 
related  to  terrorism.”  This  directive  was  supplemented  in  2004  by 

HSPD-11,  Comprehensive  Terrorist-related  Screening  Procedures.  This 
directive  refines  and  expands  screening  processes. 

NSPD-59/HSPD-24,  Biometrics  for  Identification  and  Screening  to 
Enhance  National  Security.  This  was  signed  in  2008.  This  directive  “establishes  a 
framework  to  ensure  that  federal  executive  departments  and  agencies  use 
mutually  compatible  methods  and  procedures  in  the  collection,  storage,  use, 
analysis,  and  sharing  of  biometric  and  associated  biographic  and  contextual 
information  of  individuals.” 
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HSPD-12,  Policy  for  a  Common  Identification  Standard  for  Federal  Em¬ 
ployees  and  Contractors,  was  issued  by  the  President  in  August  2004.  According 
to  the  Directive: 

“Wide  variations  in  the  quality  and  security  of  forms  of  identification  used 
to  gain  access  to  secure  federal  and  other  facilities  where  there  is  potential  for  ter¬ 
rorist  attacks  need  to  be  eliminated.  Therefore,  it  is  the  policy  of  the  United  States 
to  enhance  security,  increase  government  efficiency,  reduce  identity  fraud,  and 
protect  personal  privacy  by  establishing  a  mandatory,  government-wide  standard 
for  secure  and  reliable  forms  of  identification  issued  by  the  federal  government  to 
its  employees  and  contractors  (including  contractor  employees).” 

Additionally,  several  OMB  policy  memoranda  have  been  issued  in  recent 
years  that  describe  security  and  privacy  rules  for  PII.  These  are  in  addition  to 
OMB  guidance  on  statutes  like  the  Privacy  Act  and  Section  208  of  the  E- 
Government  Act  of  2002.  Since  IdM  systems  by  definition  will  contain  PII,  these 
requirements  will  need  to  be  applied  to  IdM  systems.  Beginning  in  May  2006, 
OMB  reminded  agencies  of  their  existing  obligations  under  the  Privacy  Act  to 
protect  PII.  Then,  OMB  issued  memorandum  M-07-16  that  set  forth  additional 
security  measures  for  information  technology  storing  data  and  additional  privacy 
requirements  related  to  reduction  of  PII  holdings  and  Social  Security  number  us¬ 
age. 

The  Information  Sharing  Environment  (ISE)~  is  another  initiative  that  has 
consequences  for  IdM  systems.  The  ISE  was  created  by  Section  1016  of  the  Intel¬ 
ligence  Reform  and  Terrorism  Prevention  Act  of  2004,  which  in  turn  was  based 
on  Executive  Order  13356,  “  Strengthening  the  Sharing  of  Terrorism  Information 
to  Protect  Americans,  Aug.  27,  2004  (subsequently  replaced  with  Executive  Order 
13888).  The  Executive  Order  directed  agencies  to  give  the  “highest  priority”  to 
the  prevention  of  terrorism  and  the  “interchange  of  terrorism  information  [both] 


21  http://www.ise.gov/ 

22  http://www.whitehoiise.gov/news/releases/2004/Q8/20Q4Q827-4.html 
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among  agencies”  and  “between  agencies  and  appropriate  authorities  of  states  and 
local  governments.”  The  President  further  directed  that  this  improved  infonnation 
sharing  be  accomplished  in  ways  that  “protect  the  freedom,  information  privacy, 
and  other  legal  rights  of  Americans.”  So,  to  the  extent  that  IdM  systems  contain 
terrorism  information,  the  rules  of  the  ISE  will  apply,  which  include  privacy 
guidelines  that  must  be  followed.  IdM  systems  used  for  purposes  of  validating 
identity  at  border  crossings  will  certainly  be  affected  by  the  ISE  rules. 

The  National  Institute  of  Standards  and  Technology  (NIST)  has  also 
promulgated  standards  such  as  the  FIPS  199,  Standards  for  Security  Categoriza¬ 
tion  of  Federal  Information  and  Information  Systems,  and  FIPS  200,  Minimum 
Security  Requirements  for  Federal  Information  and  Information  Systems,  that  re¬ 
quire  agencies  to  conduct  certain  assessments  of  the  infonnation  held  in  their  in¬ 
formation  technology  systems. 

2.4.3  Standardized  Expression  of  Identity 

One  issue  touching  on  both  policy  and  technical  architecture  is  the  lack  of 
standardized  ways  to  express  “identity,”  as  needed  to  verify  users’  claims  to  appli¬ 
cation  access.  This  study  has  discussed  “digital  identities”  and  the  essential  role  of 
these  in  any  IdM  system. 

The  fundamental  problem  today  is  that  while  there  is  well-defined  policy 
guidance  and  technical  specification  for  identity  assurance  levels, “  there  is  no 
widely  accepted  process  for  defining  and  managing  digital  identities  that  supports 
requirements  for  different  levels  of  identity  assurance.  Instead,  there  are  many 
disparate  and  autonomous  IdM  systems  that  are  based  on  locally  established  crite¬ 
ria.  New  ones  are  emerging  all  the  time. 


23  OMB  M-04-04,  E-Authentication  Guidance  for  Federal  Agencies,  December  2003  and  NIST 
Special  Publication  800-63,  Electronic  Authentication  Guideline,  April  2006. 
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A  limited  solution  to  this  problem  may  be  found  in  the  concept  of  “federa¬ 
tions.”  When  a  group  of  entities  agrees  to  use  a  common  IdM  system  concept,  it 
enables  these  entities  to  share  selected  identity  information  about  their  users  with 
others  in  defined  trust  relationships.  Such  a  sharing  arrangement  is  often  referred 
to  as  a  “federation.”  However,  this  approach  has  not  significantly  reduced  the 
number  of  disparate  identity  systems  worldwide.  It  may  also  default  to  the  lowest 
common  denominator  of  trust  (and  technical  abilities,  in  some  cases)  among  its 
subscribers.  Sponsors  sometimes  deliberately  keep  participation  requirements 
“loose”  in  order  to  attract  more  new  adherents.  Furthermore,  as  discussed  else¬ 
where,  there  are  some  privacy  concerns  associated  with  federation  that  must  be 

24 

addressed.- 

Notwithstanding  its  limitations,  federation  of  IdM  is  an  inevitable  concept, 
unless  one  would  seek  to  collect  and  store  all  relevant  data  within  a  single  data 
environment.  This  option  is  not  attractive  to  the  federal  government,  in  terms  of 
either  policy  or  technical  practicality.  Hence,  it  is  accepted  that  interoperable 
cross-organizational  collaboration  is  necessary,  between  and  among  data  stores 
and  data  holders  who  are  separated  by  organization,  distance,  and  sometimes  pol¬ 
icy.  For  this  purpose,  an  interoperable  means  of  basic  digital  identification  is  es¬ 
sential.  This  must  be  common  to  all,  and  as  rigorous  as  may  be  needed  to  support 
the  most  sensitive  application  of  identity  within  the  system. 

The  immediate  challenge  is  the  lack  of  interoperability  between  different 
IdM  systems.  Identity  information  needs  to  be  exchangeable  between  IdM  sys¬ 
tems  that  use  different  technologies,  platforms,  protocols,  data  structures,  and  ar¬ 
chitectures.  The  ultimate  solution  is  to  develop  a  standards-based,  universal 
bridging  function  that  enables  IdM  systems  and  federations  of  systems  to  com¬ 
municate  with  each  other  in  order  to  achieve  the  level  of  trust  required  for  any 
particular  transaction.  These  concepts  are  discussed  in  greater  detail  in  Annexes  E 
and  F. 


24  See  R&D  recommendation  #2,  section  4.3.1. 
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2.4.4  System  Design 


Many  considerations  may  arise  when  managing  and  overseeing  the  identi¬ 
ties  of  multiple  entities,  especially  in  large  organizations.  Following  is  a  list  of 
representative  challenges  that  have  to  be  considered  within  the  execution  of  an 
IdM  strategy. 

•  Complexity  of  task.  The  complexity  of  the  existing  IdM  environ¬ 
ment  will  make  the  task  of  mapping  the  data  model  difficult  and 
extensive.  As  discussed,  the  current  federal  IT/IdM  system  lacks 
any  overall  concept  or  framework.  Nonstandard  development  tech¬ 
niques;  taxonomy,  terms,  and  definitions;  disparate  system/process 
ownership  will  complicate  any  comprehensive  census  of  the  cur¬ 
rent  environment. 

•  Complexity  of  the  data  model.  In  order  to  share  data  between  these 
systems,  it  is  necessary  to  engineer  sometimes  complex  profiles  (or 
data  filters)  to  convert  data  from  one  system  to  a  usable,  compati¬ 
ble  form  into  another  system.  Data  structures  and  naming  conven¬ 
tions  are  inconsistent.  Same  data  is  often  represented  by  different 
field  names.  Differing  database  management  service  technologies 
can  make  data  filtering  problematic. 

•  System  Interoperability/Interworking.  This  is  conducted  on  any  of 
several  ad  hoc  models,  which  may  vary  according  to  local  or  tran¬ 
sient  needs.  For  this  reason,  the  quality  of  system/configuration 
management  may  vary  widely. 

•  Life  Cycle  management.  Life  cycle  management  refers  to  the  es¬ 
tablishment,  proofing,  modification,  suspense,  termination,  archiv¬ 
ing,  and  possible  reallocation  of  identity  data. 

•  User  control  of  data.  Any  system  involving  human  IdM  may  en¬ 
counter  conflict  between  the  desire  of  systems  and  authorities  to  be 
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able  to  identify  individuals,  and  the  desire  of  those  persons  to  con¬ 
trol  the  use  of  PII  about  them,  specifically  personal  identity  infor¬ 
mation.  Future  IdM  systems  must  acknowledge  and  confront  this 
issue,  leading  to  solutions  that  meet  all  needs. 

•  Organizational  control  of  data.  The  use  of  classic  security  tech¬ 
nologies  and  IdM  architectures  (e.g.,  federation)  may  result  in  in¬ 
creased  access  to  information  stores,  thereby  leading  to  an 
increased  potential  for  abuse.  The  use  of  simple  anonymity  tech¬ 
niques  to  achieve  privacy  protection  leaves  the  system  without  au¬ 
diting  mechanisms  that  are  required  in  many  scenarios.  This  may 
cause  a  conflict  between  security  and  privacy  that  will  leave  nei¬ 
ther  party  satisfied.  In  addition  to  the  expectations  of  the  users,  re¬ 
lying  parties  (those  who  are  extending  information,  privileges, 
goods  or  services  to  “identified  and  authorized”  persons)  also  have 
expectations  related  to  central  authorities  protecting  their  relation¬ 
ships  with  their  users  (e.g.,  to  prevent  exposure  of  sourcing  ar¬ 
rangements  between  different  vendors,  suppliers,  and  customers). 

•  Diverse  Requirements.  The  federal  government  has  already  prom¬ 
ulgated  several  IdM  systems  employing  diverse  standards,  some  of 
which  are  large  scale,  (HSPD-12/FIPS-201,  Transportation  Work¬ 
er’s  Identification  Card  (TWIC),  First  Responder’s  Access  Card 
(FRAC),  etc.).  Beyond  these  identification  card-based  systems, 
there  are  prescribed  ID  frameworks  established  for  the  Health  In¬ 
surance  Portability  and  Accountability  Act  (HIPAA)  and  the  Sar- 
banes-Oxley  Act,  inter  alia.  Finally,  various  international  partners 
have  their  own  laws,  policies  and  public  opinions  regarding  identi¬ 
fication  and  privacy.  It  will  be  a  challenge  to  produce  a  single  IdM 
framework  that  can  support  all  federal  government  requirements. 

•  Ownership  Issues.  Whether  in  industry  or  in  the  government,  enti¬ 
ties  are  usually  reluctant  to  give  up  exclusive  ownership  of  their 
data  or  to  permit  automatic  access  to  proprietary  data.  The  reasons 
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for  the  reluctance  are  not  necessarily  the  same  for  industry  and 
government,  but  without  trust,  it  will  be  difficult  to  provide  access. 

•  Standards.  The  availability  of  needed  technical  and  process  stan¬ 
dards,  and  their  adherence,  is  foundational  to  the  development  of 
any  large-scale  IdM  system.  This  will  only  be  increasingly  true 
over  time,  as  the  federal  government  seeks  to  increasingly  interop¬ 
erate  with  partnering  organizations. 

•  Streamline  IdM  Systems.  The  implementation  of  IdM  systems  de¬ 
signed  to  leverage  new  identity  credentialing  programs  (such  as  the 
PIV  card  for  federal  employees,  First  Responder  Authorization 
Cards  (FRAC)  etc.),  consolidate  capabilities,  or  enable  single  sign- 
on  processes  may  result  in  a  reduction  of  the  number  of  registra¬ 
tions  and  enrollments  users  are  required  to  undergo,  resulting  in  a 
decrease  in  the  number  of  digital  identities  that  users  must  main¬ 
tain  and  providers  must  manage.  However,  single  sign-on  is  a  chal¬ 
lenge  in  a  nomadic  environment  where  the  access  profiles  must  be 
available  from  random  locations.  It  also  may  be  a  challenge  be¬ 
cause  users  have  different  roles  in  different  situations.  The  chal¬ 
lenge  is  to  design  an  IdM  framework  that  can  support  a  single  sign- 
on  scenario  while  distinguishing  between  various  roles  that  a  spe¬ 
cific  user  may  play. 

2.4.5  Taxonomy 

As  noted,  one  of  the  challenges  in  any  effort  to  approach  IdM  is  found  in 
the  proliferation  of  diverse  taxonomy,  as  adopted  over  time  by  myriad  legacy  pro¬ 
grams.  Achieving  consensus  on  a  broad  and  adaptive  taxonomy  is  in  the  critical 
path  to  overall  success  in  harmonizing  IdM  efforts  across  government.  See  Annex 
K  for  the  IdM  Glossary  used  by  the  ITU-T  international  standards  efforts,  which 
is  adopted  here. 
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3  THE  PROPOSED  FRAMEWORK 


This  is  a  vision  for  a  government-wide  IdM  framework.  It  seeks  to  define 
and  describe,  to  the  extent  possible  today,  the  values,  priorities,  and  policies  that 
such  a  development  must  uphold.  It  will  do  so  in  context  of  the  dual  interests  of 
achieving  the  potential  improvements,  savings,  and  efficiencies  inherent  in  IdM, 
while  enhancing  privacy  relative  to  the  status  quo.  In  so  doing,  the  major  architec¬ 
tural  elements  of  the  future  system,  their  relationship  to  each  other,  the  data  used 
within  the  system,  and  the  various  organizational  and  individual  equities  involved, 
will  all  be  discussed.  To  this  end,  we  make  the  following  assumptions: 

•  Identity  and  the  management  of  all  the  personal  identifiable  quali¬ 
ties  of  identity  information  are  considered  a  critical  asset  in  sustaining 
our  security  posture. 

•  To  the  extent  available  and  practicable,  a  very  high  confidence  in 
an  asserted  identity  is  recommended  as  the  basis  for  authorization  for 
access  to  government  applications  regardless  of  assurance  level  re¬ 
quired.  For  example,  PIV  credentials  required  by  HSPD-12  and  used 
by  federal  employees  and  contractors  are  available  and  provide  for  a 
very  high  level  of  confidence  and  could  be  used  for  accessing  all  ap¬ 
plications  —  even  those  requiring  lower  levels  of  assurance. 

•  There  is  an  expectation  that  revocation  of  identity  data  and  the  re¬ 
lated  authorizations  are  executed  in  accordance  with  government-wide 
standards  throughout  all  applications  (whether  used  to  support  logical 
or  physical  access.) 

•  There  is  an  understanding  that  management  and  protection  of  iden¬ 
tity  is  not  the  responsibility  of  any  one  or  a  few  federal  agencies,  but 
rather  the  responsibility  of  all  federal  agencies  to  enable.  Identity  is  a 
component  of  each  and  every  transaction.  If  one  federal  agency  fails  to 
carry  out  their  responsibility,  access  to  our  networks  and  facilities  will 
be  significantly  jeopardized. 

The  most  important  point  to  make  at  the  onset  of  this  discussion  of  “the 
future  of  IdM”  is  that  it  is  not  just  about  people.  While  the  government  is  primar¬ 
ily  concerned,  as  a  matter  of  public  policy,  with  the  rights  and  privacy  of  persons 
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in  the  context  of  IdM  (this  will  be  discussed  at  length  in  this  report),  at  the  same 
time,  certain  trends  in  technology  must  necessarily  be  accounted  for  in  the  course 
of  the  discussion.  These  trends  will  strongly  influence  the  evolution  of  the  in- 
creasingly-mobile  IT  architecture. 

Both  screening  and  access  processing  are  discussed  in  this  report.  A  pri¬ 
mary  difference  will  remain,  however,  as  regards  to  the  handling  of  PII  in  support 
of  the  two  functions,  and  this  will  be  discussed  in  some  detail. 

Finally,  it  is  important  to  note  that  the  proposed  framework,  described 
herein,  is  not  a  formal  statement  of  policy  that  requires  any  action  on  the  part  of 
existing  federal  IdM  systems  without  further  guidance.  The  Task  Force  does  not 
have  that  authority,  nor  have  there  been  sufficient  deliberations  on  the  issue 
among  the  executive  branch  to  take  such  a  step.  Rather,  this  discussion  provides  a 
common,  learned  foundation  upon  which  to  base  those  discussions  in  future. 


3.1  THE  GLOBAL  TELECOMMUNICATIONS  GRID 

The  future  of  IdM  is  predicated  on  the  use  of  information  technology  to 
support  human  interaction,  including  providing  the  ability  to  conduct  such  inter¬ 
action  at  a  distance.  This  is  done  with  the  aid  of  terminal  devices,  which  are  com- 
ponents  of  the  global  IT  infrastructure.  '  In  recent  years,  there  has  been  an 
explosive  growth  in  the  total  population  of  these  digital  end-user  devices,  with  a 
global  population  of  more  than  one  billion  personal  computers  by  the  end  of  2008 
and  two  billion  by  2015  being  credibly  forecast.-  At  the  same  time,  the  trend  to¬ 
ward  accommodating  “nomadic”  and  mobile  wireless  systems  as  a  growing  per¬ 
centage  of  that  total  has  accelerated  at  a  breathtaking  pace  —  up  more  than  5,700 
percent  in  the  18-month  period  between  June  2005  and  the  end  of  2006,  for  ex- 


25  “Global  IT  infrastructure”  is  being  used  as  a  generic  phrase  in  this  discussion.  Internal  govern¬ 

ment  networks  would  thus  be  a  subset  of  the  broader  global  network. 

26  http://www.forrester.eom/Research/Document/Excerpt/0.721 1.42496.Q0.html 
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ample.  Taken  together,  these  two  trends  lead  to  the  conclusion  that  it  is  just  as 
necessary  for  the  elements  of  the  network  to  be  able  to  recognize,  trust,  interact 
and  share  information  with  each  other,  as  it  is  for  any  given  individual  to  be  able 
to  use  such  systems  to  reach  a  distant  person,  data  store,  or  resource.  A  successful 
outcome  can  be  achieved  only  if  both  the  accessing  systems  and  the  persons  using 
them  can  establish  their  “identities,”  and  with  that,  their  authorities  and  privileges. 

Not  only  do  the  human-identifiability  outcomes  that  define  the  functional¬ 
ity  of  the  federal  IdM  system  and  the  internal  identity  structure  of  the  supporting 
IT  “network  of  networks”  have  certain  similarities,  but  they  also  possess  unique 
features  and  qualities.  Figure  4  summarizes  the  aspects  of  the  total  system  that  are 
unique  to  both  human  and  technology  domains  and  those  that  are  necessarily 
common.  Later  in  this  report,  the  concept  of  an  “interface  specification”  be¬ 
tween  specific  human-centric  ID  applications  and  the  servicing  federal  IT  system 
will  be  addressed.  This  graphic  offers  the  first  look  at  the  underlying  concepts 
supporting  that  assessment.  Subsequent  sections  will  address  several  of  the  points 
made  on  this  diagram. 


27  Networked  Nation:  Broadband  in  America,  2007.  National  Telecommunications  and  Informa¬ 

tion  Administration,  Washington,  DC,  2008.  Pg  iii. 

28  A  new  standards  initiative  of  the  ITU-T  called  X.1250,  discussed  in  greater  detail  in  Annex  J, 

embraces  this  total  domain. 
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Comprehensive  Approach  to  IdM 


FOCUS: 

TECHNOLOGY  COLLABORATIVE  USER 


•  Standards-driven  / 

•  Flexible/Adaptive  / 

>  Extensible 

■  Interoperable 

>  Gov’t/Industry  Collab.  \ 


•  Privacy 

• Applications 
Framework/Template 

•  Plug/Play  Standards 
(for  fielding/managing 
applications) 

•  Security 


•  Cross-gov't  Scope 
•User-centric 

(acceptable,  beneficial 
convenient) 

•  Outreach  Mission 
j  -  Demystify 

J  -  Bring  in  “outliers" 

/  -  Help  define  application 

opportunities,  “clusters” 


Figure  4.  Comprehensive  Approach  to  IdM 

In  IdM,  as  in  other  areas,  technology  systems  are  designed  to  support  hu¬ 
man  needs.  In  that  respect,  the  objective  architecture  for  IdM  in  the  U.S.  federal 
government  is  predicated  on  several  top-level  goals  and  characteristics.  These  in¬ 
clude: 

•  Configuration  and  operation  of  a  “network  of  networks”  to  se¬ 
curely  manage  digital  identities,  based  on  a  set  of  common  data 
elements  for  stored  PII  that  will  allow  it  to  be  leveraged  by  a  broad 
range  of  applications; 

•  Security  of  process,  data  transmission  and  storage.  This  includes 
and  embraces  all  features  of  confidentiality,  integrity,  authenticity, 
and  privacy,  including  use  of  encryption  and  multifactor  authenti¬ 
cation; 

•  Auditability  of  processes,  with  complete,  automatic,  and  secure  re¬ 
cord  keeping; 
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•  Ubiquitous  availability,  at  global  distances,  of  strong  verification 
of  stored  digital  identity  when  called  for  or  needed  to  support  an 
authorized  application; 

•  Standard s-based  connectivity,  interoperability,  and  extensibility  of 
supporting  IT  architecture; 

•  Preservation  of  application-specific  PII  data  under  control  of  appli¬ 
cation  sponsors,  with  minimal  exposure  to  unauthorized  access  or 
unnecessary  transmission  across  networks; 

•  Ability  of  prospective  application  sponsors  to  develop,  install,  and 
operate  applications  in  a  way  that  permits  the  supporting  IT  grid  to 
be  seen  as  a  freely  available,  ubiquitous  service. 

To  the  extent  that  these  require  development,  refinement  or  adaptation, 
they  will  fonn  the  basis  of  Research  and  Development  (R&D)  requirements  cited 
below. 


3.2  “PLUG-AND-PLAY”  IDENTITY  APPLICATIONS 

In  the  objective  IdM  system,  the  character  of  identity-based  applications  is 
very  diverse,  and  the  data  they  contain  and  use  is  often  unique.  This  is  the  area  in 
the  total  system,  where  end-user  value  is  recognized,  and  application-level  work 
is  performed. 

The  way  electric  power  is  used  in  homes  is  instructed  here  as  an  analogy. 
This  is  depicted  at  a  high  level  in 

Figure  5  below. 
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Electric  Power  Analogy 


UTILITY  BACKBONE 


POWER  GRID 

-  Internally  designed,  managed 

-  Exists  to  serve  end-users 

-  Standards-based 

Interoperability  across 
disparate  jurisdictions, 
ownership 


END-USER 

APPLICATIONS 

Chosen  and 
managed  by  end-user 


USER  INTERFACE 

-  Standardized 
physical  and  logical 
designs  for  "apps"  of 
different  load 
characteristics  (trust 
levels) 


Figure  5.  Electric  Power  Analogy 

Within  this  model,  individuals  decide  to  select,  purchase,  install,  config¬ 
ure,  and  operate  electric  power  appliances  in  their  homes,  based  on  their  own 
preferences,  needs,  and  resources.  Technology  providers  make  business-case  deci¬ 
sions  regarding  the  design  and  marketing  of  new  appliances  to  consumers  and  or¬ 
ganizations,  including  federal  agencies.  In  the  process,  they  ascertain  whether  the 
device,  by  its  nature,  will  require  “low”  (120  volt),  “medium”  (220  volt),  or  high¬ 
er-level  electric  power  to  support  its  use.  In  all  cases,  the  designers,  vendors,  mar¬ 
keters,  and  end-users  are  confident  that  the  appliances  will  function  in  place, 
based  on  adherence  to  standardized  specifications  for  interface  with  the  servicing 
utility,  which  provides  the  capability  to  operate  the  devices  at  each  of  several 
standardized  levels  of  performance  —  the  electric  power  grid. 

For  its  part,  the  grid  is  enonnously  complex  internal  to  itself,  with  myriad 
entities,  jurisdictions,  regulatory  bodies,  authorities,  and  business  arrangements. 
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However,  it  understands  that  it  exists  to  deliver  a  suite  of  products,  conformant  to 
specifications,  to  the  three-pronged  outlets  in  the  wall  of  all  end-users  —  in  the 
United  States,  120  volt,  60-cycle  alternating  current.  The  utility  also  provides,  in 
many  cases,  standardized  product  at  220  or  even  440  volt  levels,  if  the  user  speci¬ 
fies  such  a  need  (as  for  heavy  appliances).  These  “interfaces”  (plugs)  have  unique 
physical  design  characteristics  appropriate  to  their  use. 

Viewed  from  the  outside,  the  electric  power  grid  is  a  complex  singularity, 
not  directly  controllable  by  end-users.  On  the  other  hand,  the  grid  can  exert  no 
direct  influence  on  buying  and  operating  decisions  of  end-users.  Both  know  that 
their  reliance  on  the  other  is  predicated  on  mutual  compliance  with  interface  spe¬ 
cifications  and  standards,  within  a  set  of  business  arrangements  that  are  estab¬ 
lished  and  regulated  with  governmental  oversight,  in  most  cases. 

The  future  federal  IdM  system  can  be  seen  in  a  similar  light.  The  global  IT 
grid  may  be  characterized  as  a  utility  that  exists  to  deliver  defined  services,  while 
having  no  control  over,  or  visibility  within,  the  details  or  content  of  standards- 
compliant  applications.  Nonetheless,  these  applications  depend  completely  on  the 
servicing  IT  grid  to  provide  identity  verification  of  registered  participants,  and  to 
conduct  data  transactions  at  global  distances,  with  high  availability,  complete  con¬ 
fidentiality,  and  confident  data  and  transaction  integrity. 

In  this  context,  identity  application  developers  would  be  obliged  to  build 
to  standards,  for  access  to  not  only  the  data-transport  process,  as  at  present,  but 
the  larger  federal  IdM  system.  Through  IT  connectivity,  these  applications  would 
be  able  to  access  stored  digital  identities  inside  the  digital  ID  “network  of  net¬ 
works.”  With  adherence  to  these  standards,  the  common  elements  of  the  federal 
IdM  system  would  be  freely  available  to  applications,  their  developers,  sponsors 
and  users.  At  the  same  time,  these  “standard  services”  to  support  ID  applications 
are  offered  at  several  different  levels  of  trust,  as  appropriate  to  the  need/nature  of 
the  specific  application.  The  ancillary  benefit  is  that  exposure  of  the  most  sensi¬ 
tive,  contextual  application  data  would  be  restricted  to  the  application  and  its  au¬ 
thorized  participants. 
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At  the  outset  of  this  report,  a  simple  model  of  the  basic  elements  of  the 
IdM  system  was  displayed  (Figure  1).  Adapting  that  model  to  all  subsequent  anal¬ 
ysis  and  discussion,  the  resultant  model  of  the  objective  system  is  shown  in  Figure 
6. 


Objective  IdM  Architectural  Model 


ID  SPECIFIC 
“PRIVELEDGES” 

(Applications  of  ID  In 
specific  context),  with 
data  unique  to  each 


Figure  6.  Objective  IdM  Architectural  Model 

In  this  environment,  the  business  case  for  development  and  operation  of 
new  applications  will  be  based  on  recognition  of  value  and  specific  measurable 
benefit  to  the  sponsor  and  the  supported  enrollees. 

As  implemented  within  the  federal  government,  the  value  proposition  for 
development  of  any  new  application  can  respond  to  any  of  several  motivators: 

•  Legal  compulsion  (e.g.,  tax  collection); 
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•  Voluntary  transition  of  traditional  functions  to  more  efficient 
means  to  perform  the  same  purpose  (e.g.,  making  formerly  print- 
based  information  resources  available  online); 

•  Creation  of  new  functionality  not  previously  available,  based  on: 

o  Geography  (e.g.,  telemedicine,  medical  robotics); 

o  Scale  (e.g.,  disaster  response); 

o  Emergent  topical  need  (e.g.,  more  stringent  security  controls  in 
air  travel  to  prevent  terrorism;  other  applications  to  restore  user 
convenience  partly  lost  in  the  course  of  meeting  anti-terror 
needs,  e.g.,  to  control  access  to  government  facilities  or  certain 
disaster  areas). 

3.3  DIGITAL  IDENTITIES  WITHIN  A  “NETWORK  OF  NET¬ 
WORKS” 

Regarding  data  content  and  function,  any  IdM  activity  requires  informa¬ 
tion  sufficient  to  develop  the  digital  identity  of  persons  within  the  system.  These 
data  must  conform  to  standards  specified  for  use  within  and  across  the  system.  It 
has  been  noted  that  standardized  ways  of  expressing  these  digital  identities  must 
be  developed  to  promote  interoperability.  These  must  also  be  accessible,  wherever 
located,  as  needed  to  establish  and  verify  identity  of  persons  asserting  roles  or 
privileges.  However,  these  data  need  not  be  excessive  and  should  certainly  not 
express  or  reveal  the  contextual  data  associated  with  any  specific  ID  application. 

For  example,  if  it  is  necessary  to  establish  that  a  given  person  is  John  Doe, 
in  order  to  pennit  him  to  view  and  work  with  classified  infonnation,  this  may  be 
achieved  by  comparing  some  identity  credential  (user  ID/password/PIN/ID  card, 
etc.)  in  his  possession;  or  biometric  values  (fingerprint,  photo,  iris  scan,  etc.)  of 
that  person  to  reference  values  collected  and  stored  at  the  time  Mr.  Doe  was  en¬ 
rolled  in  the  system.  If,  an  hour  later,  the  same  person  then  seeks  to  access  health¬ 
care,  claiming  to  be  an  entitled  beneficiary  as  a  consequence  of  his  federal 
employment  status,  the  same  interest  in  identifying  him  for  purposes  of  verifying 
that  “privilege”  occurs,  and  possibly  the  same  means  may  be  used  to  do  so.  How¬ 
ever,  in  neither  case  was  or  is  it  necessary  to  expose  the  contents  or  details  of  his 
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participation  “inside”  these  processes  —  classified  information  he  works  with,  or 
details  of  his  medical  history  —  to  confirm  or  deny  his  basic  identity  and  access 
to  the  relevant  privilege  application.  It  is  most  certainly  not  necessary  to  expose 
these  content-data  specifics  to  managers  of  the  other  identity-related  activity;  all 
would  surely  agree  that  the  two  have  nothing  to  do  with  each  other,  and  would  all 
find  it  an  objectionable  violation  of  privacy  if  that  were  to  be  done,  most  espe¬ 
cially  without  the  individual’s  knowledge. 

Implicit  in  the  foregoing  point  is  the  fact  that  there  are  multiple  levels  of 
confidence,  or  “trust,”  in  the  digital  ID  universe.  These  are,  and  will  be,  based  on 
identity-proofing  standards  adopted  by  policy  frameworks  at  the  advent  of  devel¬ 
opment  of  a  federated  “network  of  networks”  for  interoperability.  Also,  different 
applications  only  require  or  request  identity  confidence  to  a  specific  level  (based 
on  policies  governing  them  and  other  factors).  In  this  regard,  a  conservative  prin¬ 
ciple  shall  apply  —  only  expose  identity  data  (in  the  fonn  of  attributes)  sufficient 
to  support  the  needs  of  the  application,  and  no  further.  In  some  cases,  for  some 
applications,  users  may  be  able  to  decide  for  themselves  to  voluntarily  expose 
more  or  less  sensitive  private  infonnation,  in  order  to  access  different  levels  of 
service. 


There  will  also  be  differences  in  the  level  of  identity  confidence,  as  needed 
to  support  accurate  authentication  decisions,  based  on  the  use  (or  non-use)  of  sup¬ 
porting  authentication  mechanisms  of  three  types: 

•  Something  you  are  (biometrics); 

•  Something  you  know  (PIN/password); 

•  Something  you  possess  (ID  card  or  similar  physical  token). 

Ideally,  the  nature  of  the  mechanism  selected,  and  the  way  it  is  used,  will 
be  driven  by  the  level  of  trust  being  sought  at  the  application  level.  The  combina¬ 
tion  of  two  or  more  of  these  authentication  mechanisms  may  also  affect  the  level 
of  trust  attributed  to  the  identity  assertion.  Considerations  related  to  scalabil¬ 
ity/management,  user  convenience,  and  security  all  enter  into  the  decision  process 
in  this  area. 


54 


In  approaching  this  subject,  the  U.S.  federal  government  has  one  huge  ad¬ 
vantage  over  most  organizations.  The  existence  of  HSPD-12,  as  described,  has 
provided  a  policy  and  standards  basis  for  basic  identification  of  federal  employ¬ 
ees,  and  some  designated  others,  to  a  standard  that  is  robust,  interoperable,  and 
mandatory  across  the  federal  establishment.  The  directive  levels  the  bar  across  all 
federal  departments  and  agencies,  and  sets  it  at  a  high  level.  This  means  that  when 
the  process  of  HSPD-12  adoption  is  complete  across  the  government,  there  will 
be  a  rigorous  basis  upon  which  to  predicate  the  kinds  of  applications  development 
discussed  above,  using  sophisticated  mechanisms  across  the  global  IT  grid  to  link 
the  applications  and  digital  ID  stores.  The  HSPD-12  identity,  however,  does  not 
apply  to  many  groups  and  individuals  that  interact  with  government  systems.  It  is 
these  non-HSPD- 1 2-idcntificd  individuals  for  whom  further  discussion  and  analy¬ 
sis  will  be  required  to  detennine  how  best  to  provide  needed  support. 

Foundational  work  in  this  area  was  conducted  by  the  federal  government 
within  the  past  several  years,  under  auspices  of  the  E-Authentication  Initiative,  as 
previously  discussed.  Of  note,  there  are,  and  will  continue  to  be,  ID  systems  and 
applications  that  use  authentication  mechanisms  (biometrics,  use- 
rid/password/PIN,  ID  card),  of  various  types,  and  often  in  combination.  The  ob¬ 
jective  federal  IdM  system  must  continue  to  accommodate  this  flexibility,  while 
also  striving  to  improve  authentication  implementations  for  all  systems. 

It  has  been  established  that  digital  identities,  consisting  of  PII  in  the  form 
of  identity  attributes,  will  be  collected  and  stored  in  the  digital  ID  Network  of 
Networks.  It  has  also  been  noted  that  work  is  needed  to  define  common  attributes 
and  data  elements  that  shall  be  taken  to  comprise  usable  identities  and  that  these 
shall  occur  at  multiple  levels  of  rigor,  matching  various  levels  of  trust  in  the  iden¬ 
tity  of  the  person  in  question. 

At  the  same  time,  PII  will  be  generated  and  stored  inside  privilege  applica¬ 
tions.  However,  there  is  no  reason  why  any  PII  will  need  to  be  accessed  or  shared 
for  any  purpose  other  than  at  the  request  of  the  individual  it  identifies.  It  is  under¬ 
stood  that  these  application-specific  PII  are  often  quite  sensitive,  in  that  they  re¬ 
veal  aspects  of  the  individual  resources,  conduct,  and  personal  preferences  of 
identifiable  individuals.  A  person  may  be  willing  to  share  these  in  the  context  of  a 
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specific  application,  based  on  voluntary  enrollment,  where  a  perceived  net  benefit 
exists  (e.g.,  reporting  credit  history  on  a  loan  application,).  In  some  interactions 
with  government,  a  person  may  be  compelled  by  law  to  disclose  PII,  (e.g.,  earn¬ 
ings  history  to  the  Social  Security  Administration).  The  general  case,  however,  is 
that  individuals  should  be  able  to  largely  choose  to  associate  with  specific  ID  ap¬ 
plications,  and  certainly  know  in  which  ones  they  are  enrolled.  OMB  memoran¬ 
dum  M-07-16,  Safeguarding  Against  and  Responding  to  the  Breach  of  Personally 
Identifiable  Information,  provides  additional  guidance  to  federal  agencies  con¬ 
cerning  the  protection  and  use  of  PII. 

Consolidating  and  streamlining  credentialing  of  the  federal  workforce 
through  HSPD-12,  then  leveraging  PIV  credentials  as  a  principal  means  for  ac¬ 
cessing  applications,  provides  increased  security  through  two-factor  authentica¬ 
tion.  Thus,  two-factor  authentication  is  among  the  highest  priorities  for  IdM 
functionality  internal  to  the  federal  government.  In  addition,  it  enhances  the  capa¬ 
bility  of  single  sign-on  (SSO)  solutions  to  ease  the  burden  on  the  individual. 

In  discussing  SSO  within  government,  privacy  goals  are  enhanced  by  en¬ 
suring  the  preservation  of  strong  barriers  between  applications,  in  regards  to  the 
passage  of  PII  between  them.  While  it  is  possible  to  streamline  the  access  of  per¬ 
sons  or  entities  to  accessing  multiple  apps,  it  is  essential  that  transactions  internal 
to  them  remain  unique  to  each  and  not  be  shared.  In  these  ways,  the  convenience 
of  SSO  can  be  achieved  within  government  use,  while  preserving  application- 
level  privacy.  The  commingling  or  sharing  of  data  between  applications  is  gener¬ 
ally  objected  to  on  the  basis  that  one  application  has  nothing  to  do  with  the  other. 


Who  we  are  is  sensitive  to  us  in  some  times  and  places; 
What  we  have,  believe,  and  choose  to  do  almost  always  is... 
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This  point  is  pivotal  when  both  the  scope  and  scale  of  the  objective  archi¬ 
tecture  are  considered.  A  federal  IdM  architecture  will  and  should  be  defined 
within  the  scope  specified  at  the  outset,  which  will  necessarily  extend  across 
boundaries  of  jurisdiction  (and  thus,  different  laws  and  social  views/cultures), 
technology  approaches,  nature  of  applications,  etc.  This  architecture  will  not  be 
“monolithic,”  but  will  represent  a  complex  of  disparate  machines  and  processes, 
able  to  work  harmoniously  through  development  of,  and  adherence  to,  standards 
to  achieve  interoperability.  This,  in  turn,  would  further  support  stronger  privacy 
protections,  because  data  governance  policies  can  be  developed  and  implemented 
—  even  implemented  mechanically  through  physical  control  —  at  the  data  source 
where  the  context  and  purpose  for  collecting  this  information  originated.  The 
unique  type  of  granular  control  is  much  harder  to  manage  and  confirm  if  data  is 
sent  from  multiple  sources  to  a  single  centralized  location.  It  can  not  be  empha¬ 
sized  enough  that  this  centralized  data  store  approach  is  NOT  being  recom¬ 
mended.  The  applications  supported  by  this  architecture  will  be  enormously 
diverse,  as  will  the  nature  of  the  content-specific  data  they  use  and  retain  (medical 
records,  financial  transactions,  security  clearances,  data  files,  business  records, 
etc.).  At  the  same  time,  the  scale  of  the  object  architecture  will  be  global  and  mas¬ 
sive,  as  needed  to  support  the  full  range  of  federal  government  activities  and  en¬ 
rolled  participants.  This  latter  consideration  will  inform  architectural  planning 
regarding  design  capacity  and  system  performance  under  stress. 

In  Section  2,  the  current  state  of  IdM  within  the  federal  government  was 
described.  Among  the  central  conclusions,  it  was  found  that: 

•  There  is  much  duplication  of  the  collection  and  storage  of  basic 
identification  data  across  the  federal  enterprise; 

•  The  currently  deployed  architecture  demonstrates  considerable  di¬ 
versity  in  formats  and  standards  of  data  element  design  and  stor¬ 
age; 

•  In  some  cases,  sensitive,  application-level  “contextual”  data  are 
exposed  in  transmission,  or  duplicated  across  applications. 

In  contrast  to  that,  an  IdM  environment  is  proposed  in  which: 
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•  Identity  attributes  necessary  to  support  the  development  of  digital 
ID  are  standardized  to  the  extent  possible; 

•  These  digital  identities  would  be  stored  within  the  IT  architecture 
in  ways  that  make  them  accessible  by  ID  applications;  they  would 
be  used  for  purposes  of  verifying  identity  upon  enrollment,  or  as¬ 
sertion  of  entitlement  to  access  a  privilege  application; 

•  Data  associated  with  an  individual’s  activities  in  any  specific  ap¬ 
plication  would  be  held  in  and  by  the  application  sponsor,  in  what 
ever  fonnat  was  appropriate  to  that  activity  or  the  user  convention 
in  that  application;  in  general,  these  would  not  be  shared  with  other 
applications;  their  availability  to  any  others  would  be  governed  by 
law  and/or  voluntary  use  agreement  executed  upon  enrollment. 


3.4  IMPLICATIONS  FOR  PRIVACY  IN  THE  PROPOSED 
STATE 

The  case  has  been  made  that  the  current  IT  architecture  consists  largely  of 
stand-alone,  “stovepipe”  systems,  unique  data  paths,  and  duplicative  PII  reposito¬ 
ries  in  diverse  formats,  often  at  the  application  level.  As  such,  differences  exist  in 
the  ways  the  same  PII  and  other  information  are  retained,  portrayed,  weighted, 
and  valued  across  the  total  data  architecture.  Further,  the  existence  of  these  dupli¬ 
cative  and  non-standard  data  increases  opportunity  for  data  exploitation  and  unau¬ 
thorized  access,  and  multiplies  the  likelihood  that  data  will  be  stored,  updated, 
and  retained  inconsistently  across  the  architecture.  These  current  threats  to  data 
integrity  and  privacy  are  summarized  in  Figure  7. 
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Personal/Data  Privacy 
Implications  —  Current 


APPLICATION  LAYER: 

-  Sensitive,  application- 
unique  data  exposed 
throughout  system 

TRANSPORT  LAYER: 

-  Numerous  opportunities 
for  penetration,  data 
exposure  in  transit  (lowest- 
common-denominator 
security  model 

DIGITAL  ID  LAYER: 

-  Risk  of  error,  fraud 

-  Needless  expense 
through  duplication 

-  Exposure  risk  due  to 
redundancy  in  multiple 
locations  of  uneven 
security 
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Figure  7.  Privacy  Implications  of  Historic  Approaches  to  ID  Architecture. 


In  dealing  with  these  concerns,  the  Task  Force  postulates  a  federal  identity 
implementation  featuring  much  more  commonality  within  and  across  the  IT- 
service  process,  including  cross-organizational  and  cross-domain  interoperability 
within  a  scalable,  federated  “network  of  networks.”  This  architecture  would  con¬ 
tain  PII  as  required  to  support  basic  identification  but  not  application-specific  da¬ 
ta.  Individual  applications  would  use  a  predefined  process  for  querying  data  stores 
in  order  to  verify  a  claimed  identity.  In  so  doing,  the  opportunity  exists  to  envision 
a  more  privacy-sensitive  approach  to  IdM,  which  should  encourage  the  develop¬ 
ment  and  use  of  more  and  higher-performing  identity  applications.  The  effect  of 
the  evolved  objective  architecture,  pertaining  to  privacy,  can  be  made  to  look  like 
the  situation  depicted  in  Figure  8. 


The  conditions  depicted  in  Figure  8  suggest  organizations  seeking  to  de¬ 
velop  or  improve  identity  applications  to  perform  their  missions  will  be  able  to  do 
so  with  confidence  in  the  availability  of  an  accessible,  secure,  and  robust  federal 
IdM  system  “at  their  doorstep.”  This  will  not  only  permit  such  organizations  to 
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achieve  efficiencies  and  improve  service,  but  to  do  so  in  ways  that  will  improve 
upon  the  handling  of  PII  and  sensitivity  to  privacy  issues. 


Personal/Data  Privacy 
Implications  —  Objective 


-  Private  application- 
specific  attributes  NOT 
exposed  to  “Utility" 

-  EACH  application 
contains/retains  only 
those  attributes  and 
records  appropriate  to 
ITSELF 


Application/user 


Interface 


IDENTITY  MANAGEMENT  “UTILITY’ 

-  Common/standards-based 
management  of  storage,  transport 
reduces  vulnerability 

-  Stored  personal  data 
supports  basic  ID 
verification  ONLY 


T 


J 


Figure  8.  Privacy  Concept  in  the  Objective  State  of  IdM 


3.5  SUMMARIZING  THE  CHANGE  OVER  TIME 

Many  federal  IdM  systems  today  are  completely  unique  in  their  ap¬ 
proaches  to  technology,  standards,  and  data  management.  This  contributes  to  the 
complexity  that  has  made  IdM  the  purview  of  organizations  and  individuals  with 
deep  technical  skills,  and  tended  to  discourage  those  whose  only  experience  in  the 
subject  is  that  they  have  a  job  to  do  in  the  public  interest,  which  either  requires  or 
will  work  better  with  a  more  effective  and  efficient  IdM  solution. 
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In  order  to  achieve  its  full  potential,  IdM  must  evolve,  over  time,  from  be¬ 
ing  a  domain  reserved  for  expert  technical  practitioners,  to  the  status  of  broad  so¬ 
cial  acceptance  as  a  useful  and  practical  tool.  In  that  regard,  it  is  possible  to 
envision  advanced  approaches  to  IdM  as  the  critical  path  to  achieving  consensus 
on  complex  and  important  social  issues.  By  making  the  IdM  process  more  ac¬ 
cessible  over  time,  the  whole  subject  will  be  better  understood  by  the  public,  the¬ 
reby  gamering  increased  acceptance  and  fostering  industry  development  of 
entrepreneurial  approaches  that  will  result  in  improved  end-use  capabilities. 

It  is  possible  to  achieve  great  strides  in  this  area  within  the  next  few  years. 
That  assertion  considers  the  state  of  development  of  technology;  the  extent  to 
which  IdM  is  being  driven,  in  direction  and  pace,  by  threat-based  factors,  and  the 
potential  pace  of  public  embrace  of  govermnental  identity-based  programs  and 
value-based  capabilities.  On  the  basis  of  those  assumptions,  the  near  future  of 
IdM  can  be  predicted  as  shown  in  Figure  9. 


In  the  early  days  of  the  automobile,  one  needed  a  real  understanding  of  in¬ 
ternal-combustion  engine  technology  to  make  a  car  start  and  run;  today  one  need 
only  turn  a  key,  almost  all  of  the  time. 

So  it  will  be  with  IdM ...  today’s  dauntingly  complex  technical  processes 
will  give  way,  over  time,  to  invisible,  ubiquitous  service  —  the  “ dial  tone ”  that  is 
simply  “there,  ”  ready  to  serve  our  needs  . . . 


29  See,  inter  alia, 

http://energycommerce.house.gov/Press  110/JAC. Report  FINAL %20Jan, 3. 2008. pdf,  a  Con- 


61 


Now  vs.  Then 
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Controlling  Equity: 


Cultural  Character: 


“Appearance”: 


TODAY  FUTURE 


Data  sets  I  Applications 


Standards;  Social  I  Scalability;  Business 

Acceptamce  I  Models 


Federal  IT  community  Balanced  stakeholder  equities 

-  End-uers 

-  Application  sponsor/managers 
-  Digital  ID  Managers 
-  Global  Grid/IT  managers 


Service-provider  push  I  User-demand  pull 


Watchmaker’s  Shop  I  Utility  (electric  power  analogy) 


Figure  9.  Federal  IdM,  2008  vs.  Future 


gressional  report  on  potential  improvements  in  healthcare  through  use  of  advanced  IT  ap¬ 
proaches  and  capabilities. 
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4  RECOMMENDED  ACTIONS  WARRANTING  FED¬ 
ERAL  COORDINATION 

As  previously  stated,  this  report  provides  a  vision  upon  which  to  base  a 
number  of  follow-on  analyses  and  discussions.  These  will  lead  to  the  identifica¬ 
tion  of  specific  policy  and  technology  tasks.  However,  there  are  a  number  of 
agenda  items  that  plainly  need  to  be  addressed,  and  that  can  be  initiated  concur¬ 
rently,  even  immediately.  In  some  cases,  these  will  begin  within  a  general  discus¬ 
sion  framework,  and  progressively  becoming  more  specific  over  time. 

4.1  STANDARDS  &  GUIDANCE 

The  development  and  management  of  the  kind  of  IdM  framework  de¬ 
scribed  here  will  not  be  possible  without  development,  adoption,  and  adherence  to 
a  number  of  technology  and  process  standards.  Some  of  these  have  not  yet  been 
completed  or  ratified  for  adoption;  in  other  cases,  development  has  not  yet  begun. 
The  Task  Force  considers  this  aspect  of  work  to  be  among  the  most  critical  in 
achieving  the  potential  value  and  benefits  of  IdM. 

4.1.1  Standards  Bodies 

International  standards  will  need  to  be  developed  over  the  next  decade  to 
implement  the  conceptual  model  of  the  global  IdM  framework  described  above. 
The  U.S.  will  need  to  participate  actively  in  the  international  organizations  that 
develop  these  standards  in  order  to  ensure  that  non-federal  IdM  systems  and  fed¬ 
erations  of  systems  will  be  able  to  interoperate  with  the  federal  government’s  IdM 
system. 


4.1.2  Application  Format,  Interface  Specification 

The  success  factors  for  a  reliable  and  interoperable  IdM  system  requires  a 
framework  consisting  of  standardized  processes  and  technical  specifications  that 
are  application  neutral,  extensible,  standards-based,  and  adoptable  by  service  pro¬ 
viders,  operating  system  vendors,  application  developers,  and  system  integrators. 
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Minimally  the  specification  should  include  a  standards-based  approach  for 
the  following: 

•  Identity  Management  framework; 

•  Application  programming  interfaces; 

•  Hardware  token  interface; 

•  Security  architecture; 

•  Conformity  testing; 

•  Authentication  protocols; 

•  Capability  discovery  mechanism; 

•  Privacy  enabling  technology; 

•  Extensibility  mechanisms. 

The  security  architecture  should  specify  levels  of  security  to  support  vary¬ 
ing  user  requirements. 

4.2  ARCHITECTURE 

Identity  Management  architecture  should  be  consistent  with  two  themes: 
the  citizen-centric,  line-of-business  approach  defined  in  the  Federal  Enterprise 
Architecture  (FEA),  and  the  wider  architectural  concept  embodied  in  the  city 
planning  model. 

The  OMB  is  developing  the  FEA  as  a  business-based  framework  for  gov¬ 
ernment-wide  improvement.  The  FEA  is  a  business-driven  approach  to  identify 
opportunities  to  simplify  processes  and  unify  work  across  the  agencies  and  within 
the  lines  of  business  of  the  federal  government.  The  outcome  of  this  effort  will  be 
a  more  citizen-centered,  customer-focused  government  that  maximizes  technol¬ 
ogy  investments  to  better  achieve  mission  outcomes.  Integral  to  the  FEA  is  the  use 
of  digital  technologies  to  transfonn  government  operations  in  order  to  improve 
effectiveness,  efficiency,  and  service  delivery. 
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Upon  migration  to  common  government-wide  solutions,  agencies 
will  shut  down  redundant  systems  which  will  not  only  save  money 
but  also  free-up  resources  for  agencies  to  better  focus  on  achieving 
their  missions. 

FY  2007  Budget,  Analytical  Perspectives  Volume,  p.  152. 


The  city  planning  model  underlies  the  basic  structure  of  internetworking. 
It  describes  how  entities  join  together  to  form  networks,  how  networks  join  to¬ 
gether  to  conduct  internetworking,  and  it  lays  out  the  fundamental  infrastructure 
requirements  needed  to  make  these  networks  interoperate.  FEA,  and  specifically 
its  Business  Reference  Model,  takes  a  cross-cutting  view  of  government  services 
in  terms  of  their  business  functions.  It  can  be  thought  of  as  defining  the  govern¬ 
ment  as  a  business  sector  in  a  model  city.  Government  services  are  grouped  to¬ 
gether  in  a  logical  way  in  order  to  facilitate  organizational  efficiency  and  citizen 
access. 


IdM  can  address  the  gap  between  the  general  city  planning  concept  and 
the  service/business  provision  model  of  the  FEA.  To  obtain  the  efficiencies  con¬ 
templated  in  the  FEA  model,  a  set  of  common  services  must  be  provided  that  al¬ 
low  the  enterprise-level  services  to  function.  The  OMB,  in  its  discussions  of  the 
federal  architecture,  describe  a  set  of  back  office  services,  similar  to  those  re¬ 
quired  to  keep  any  business  running,  such  as  accounting  or  inventory  manage¬ 
ment.  Lying  below  these,  and  just  as  critical  to  business  continuity,  are  the  utilities 
that  provide  general  services  to  all  businesses.  In  a  well-run  city,  this  crucial  layer 
includes  plumbing,  streets,  and  other  basic  services  available  to  all.  In  the  wider 
environment,  where  cities  are  connected  over  distances,  the  utility  layer  also  in¬ 
cludes  things  like  highways,  railroads,  and  satellite  telecomm  links. 

IdM  is  one  of  the  infrastructural  components  that  permits  a  network  of 
networks  to  operate,  providing  a  basic  service  that  validates  claims  of  identity  so 
that  individual  business  applications  can  determine  what  privileges  are  to  be 
granted  to  that  validated  identity.  The  IdM  architecture  proposed  here  transcends 
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the  existing  (but  nascent)  state  of  federated  identity  management.  Within- 
enterprise  efforts  have  been  ongoing,  and  several  organizations  are  working  on 
ways  to  articulate  a  standards-based  approach  to  IdM.  Among  these  are  the  activi¬ 
ties  of  the  Federal  Identity  Credentialing  Committee  (FICC)  working  with  NIST 
to  define  the  architectural  components  of  a  government-wide  IdM  solution.  The 
needed  outcome  —  a  change  from  the  status  quo  —  has  been  described  in  the 
proposed  vision. 

4.2.1  Federated  IdM  Systems:  A  Network  of  Networks 

Many  models  present  themselves  under  the  city  planning  paradigm  of  in¬ 
ternetworking.  The  public  power  grid,  municipal  water,  and  sewer  systems  offer 
examples,  as  does  the  telecommunications  system.  Each  was  built  by  connecting 
local  systems  together.  The  present  state  of  IdM  is  that  the  local  systems  have 
been  built,  but  they  have  not  been  connected  and  subjected  to  a  structured  and  ve¬ 
rifiable  process  in  order  to  realize  a  cross-organizational  trust  framework.  Because 
of  this,  identity  needs  to  be  established  with  every  local  system  to  be  used  by  a 
single  entity.  The  key  architectural  questions  that  must  be  addressed  are:  how  will 
these  cross  connections  be  made,  what  standards  will  govern  the  connections, 
what  services  will  be  provided,  and  what  will  the  governance  structure  of  the  ser¬ 
vice  look  like?  Section  4. 2. 1.1  will  address  these  issues,  but  before  proceeding,  a 
general  outline  of  the  network  architecture  is  in  order. 

The  first  round  of  human  network  building  was  characterized  by  the 
growth  and  development  of  discrete  solutions,  railways,  pipelines,  telegraph  lines, 
etc.  By  the  time  the  telephone  system  was  being  developed,  it  was  clear  that  creat¬ 
ing  a  new  networked  infrastructure  to  replace  an  old  one  is  expensive,  time- 
consuming,  and  potentially  duplicative. 

As  networks  are  built,  the  characters  of  the  applications  that  use  them 
evolve.  Simply  stated,  the  number  of  such  applications  increases,  while  the  nature 
of  functions  performed  and  services  provided  proliferate,  with  a  common  core  of 
services  evolving,  but  that  are  redundant  and  lack  the  necessary  standardization. 
This  is  the  situation  we  face  in  IdM  today.  These  predictable  characteristics  in- 
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form  our  sense  of  the  architectural  and  process  improvements  that  will  be  stan¬ 
dardized,  extensible,  scalable,  and  easy  to  design  and  use. 

At  first,  the  commercial  Internet  was  dominated  by  small  collections  of 
static  pages  that  communicated  unidirectionally.  Eventually,  more  sophisticated 
applications  were  launched  that  allowed  business  processes  to  be  run  using  the 
network  infrastructure.  Using  a  shared  infrastructure  is  clearly  preferable  in  terms 
of  time,  effort,  and  cost  to  building  or  buying  dedicated  networking  capacity,  as 
had  been  done  in  the  past.  The  IdM  architecture  being  proposed  uses  the  same 
type  of  approach  to  infrastructure,  existing  network  nodes  will  form  a  distributed 
network  by  connecting  to  each  other  across  a  common  networking  infrastructure, 
such  as  that  described  in  Section  3.  The  resulting  network  will  use  an  overlay  ar¬ 
chitecture  strategy.  Each  identity  data  custodian  will  retain  its  own  internal  organ¬ 
izational  structure.  In  practice,  this  is  generally  an  enterprise  network  consisting 
of  several  nodes  joined  in  a  private  loop.  As  part  of  an  IdM  internetworked  ser¬ 
vice,  each  of  these  nodes  will  establish  a  gateway  (set  of  tools  and  services)  that 
enables  it  to  request/respond  to  identity  verification  requests  from  other  entities. 
The  gateways  will  use  standards-based  components  such  that  each  gateway  is 
functionally  equivalent  on  the  external  internetwork-facing  side,  while  being  cus¬ 
tomized  to  what  ever  extent  is  required  for  interoperability  on  the  inward-facing 
side.  Section  4. 2. 1.2  discusses  the  necessary  components  and  their  orientation 
within  the  overall  “network  of  networks.” 

4. 2. 1.1  Scope,  content,  and  management 

The  scope  envisioned  for  the  network  is  U.S.  federal  government- wide. 
That  is,  services  will  be  provided  for  all  departments  and  agencies  of  the  federal 
government  and  intended  to  support  all  federal  missions.  Thus,  the  scope  includes 
providing  services  to  citizens  and  other  clients  of  federal  systems,  such  as  other 
agencies,  non-citizens,  other  governments,  and  business.  This  will  necessitate  a 
clear  distinction  between  the  identity  service  the  network  provides  and  the  appli¬ 
cation-specific  services  that  user  agencies  develop  and  maintain.  Details  of  the 
activities  and  functions  that  must  be  supported  are  described  in  Section  2.1.3,  as 
part  of  the  current  environment. 
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Details  regarding  the  required  data  exchange  are  a  key  issue  that  received 
much  of  the  Task  Force’s  attention.  Content  questions  include:  what  is  “identity,” 
what  is  “identity  management,”  and  what  facets  of  what  ever  it  is  that  constitutes 
identity  will  be  exchanged  in  a  networked  trust  environment?  By  limiting  the  ex¬ 
change  of  data  to  authentication  protocols,  such  as  encrypted  password,  PIN, 
cryptosequence,  PKI  signature,  or  biometrics,  using  two-factor  authentication,  and 
responding  by  affirmation  or  denial,  privacy  and  data  protection  are  considered. 

Defining  identity  is  highly  challenging  and  quickly  takes  on  the  tenor  of  a 
philosophical  discussion.  For  the  purposes  of  IdManagement,  however,  identity  is 
simply  the  collection  of  data  which  a  repository  uses  to  represent  identities  within 
a  given  infonnation  system.  The  tenn  “digital  identity”  is  used  to  describe  this 
collection  of  data.  However,  each  identity  may  be  claimed,  locally  or  globally, 
using  a  much  smaller  set  of  data  depending  on  the  authentication  protocols.  Au¬ 
thentication  mechanisms  query  IdM  systems  concerning  data  related  to  a  claimed 
identity,  to  which  the  IdM  system  will  reply  with  “yes”  or  “no,”  indicating  wheth¬ 
er  or  not  the  infonnation  in  the  query  matches  the  stored  digital  identity. 

In  common  with  other  organizations  that  rely  on  standards  bodies,  the  co¬ 
operative  would  appoint  delegates  to  the  appropriate  standards  organizations. 

4. 2. 1.2  Integration  of  Components  Within  the  Total  Sys¬ 
tem 

In  order  for  the  separate  components  that  make  up  the  network  to  function 
cohesively,  they  require  an  integration  framework.  The  current  dominant  approach 
to  this  problem  is  Service  Oriented  Architecture  (SOA).  The  SOA  style  evolved 
from  and  is  still  closely  associated  with  Web  services.  It  is  a  loosely-coupled  ar¬ 
chitecture  that  uses  standardized  middleware  components  to  enable  disparate  ap¬ 
plications  to  exchange  information.  The  goal  of  SOA  is  to  minimize  reworking  of 
existing  applications,  extend  their  useful  lives,  and  expand  their  potential  for  re¬ 
use  across  an  enterprise. 

As  SOA  emerged  in  the  early  2000s  and  applications  were  beginning  to  be 
accessed  across  enterprises,  the  issue  of  authentication  took  on  increased  promi- 
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nence.  The  ability  to  have  users  sign-on  once  and  be  able  to  access  all  of  their  au¬ 
thorized  enterprise  applications  was  obviously  needed.  The  desirability  of  an 
“identify  once,  authorize  many  places”  model  is,  in  fact,  a  key  driver  of  identity 
management  initiatives. 

SOA  was  originally  developed  for  use  within  enterprises  as  somewhat  nar¬ 
rowly  defined.  The  goal  was  to  create  a  way  for  organizations  to  tie  together  the 
many  stove-piped  applications  that  made  up  their  information  systems’  portfolios 
without  having  to  rewrite  them  to  a  common  hardware/software  platform.  SOA  is 
a  solution  to  application  proliferation  in  an  environment  of  varying  levels  of  ex¬ 
pertise,  deep  repositories  of  legacy  applications,  and  constantly  changing  infra¬ 
structure.  As  its  name  implies,  SOA  is  a  style,  or  approach,  to  information  systems 
enterprise  management.  Although  it  is  frequently  associated  with  Web  services, 
they  are  not  identical,  and  SOA  can  be  implemented  with  a  variety  of  methods 
inside  an  enterprise. 

SOA  was  not  targeted  at  internetworked  applications,  primarily  because 
they  essentially  did  not  exist  at  the  time.  Instead,  SOA  has  facilitated  the  birth  of 
specialized  networks  of  networks  that  ride  on  top  of  a  commercial  (or  other)  net¬ 
work.  In  this  context,  the  possible  configurations  of  SOA  are  more  limited,  as  a 
Web  services  model  is  the  only  practical  alternative. 

An  SOA/Web  services  architecture  is  still  emerging,  although  significant 
work  has  been  done  to  define  and  standardize  the  service  model.  Technical  details 
of  SOA  implementation  are  beyond  the  scope  of  this  document,  but  will  play  an 
important  role  in  the  success  of  an  IdM  Network. 

It  must  be  noted  that  SOA  is  not  cost-free.  Implementing  an  SOA  gateway 
requires  significant  technical  expertise,  but  even  more  cost  is  involved  in  the 
overhead  that  SOA  imposes  on  transactions.  Because  of  this  known  limitation, 
stringent  performance  testing  is  a  necessity. 

Importantly,  SOA  has  some  very  desirable  features  that  can  be  put  to  great 
advantage  for  IdM.  There  is  the  ability  to  pass  extremely  critical  information  from 
an  entity  through  the  privilege  application  in  encrypted  form  without  exposing 
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critical  information,  such  as  authentication  protocols.  This  information  can  only 
be  read  by  the  authoritative  source  for  the  identity,  which  is  known  via  discovery. 
The  IdM  system,  which  can  read  the  data,  is  authoritative  for  the  identity  claimed, 
and  it  can  provide  verification  of  the  identity  securely  back  to  the  relying  party 
application. 

This  capability  will  totally  defeat  the  phishing  attacks  that  make  use¬ 
rid/passwords/PINs  so  vulnerable.  Even  if  a  user  is  duped  into  passing  informa¬ 
tion,  such  as  a  password,  PIN,  cryptosequence,  PKI  signature,  or  biometrics,  the 
phishing  application  has  no  way  of  reading  the  data,  making  the  attack  pointless. 

4.2.2  Security  Within  the  Architecture 

Adding  further  to  the  discussion  in  section  2. 1.4.2,  the  converged  IT  and 
IdM-support  architecture  will  require  the  full  suite  of  technical,  polic,y  and  proc¬ 
ess  protections  traditionally  associated  with  Infonnation  Assurance  or  cybersecu¬ 
rity,  and  those  demanded  by  law,  policy,  and  public  opinion  that  regard  the 
protection  of  personally-identifiable  information. 

In  many  application  contexts,  and  certainly  in  that  of  IdM,  it  is  important 
to  protect  the  content  of  messages  exchanged  within  and  across  networks.  The 
role  of  security  varies  according  to  the  risks  involved  in  the  communication  trans¬ 
action.  Because  IdM  brings  with  it  risks  on  many  levels  (individual,  governmen¬ 
tal,  and  even  global),  security  is  a  principal  function  that  must  be  provided  by  the 
system.  Security  measures  can  be  provided  at  any  layer  within  a  communications 
network,  from  the  composition  of  a  message,  through  its  packaging,  emission, 
carriage,  and  reception.  Security  requirements  invariably  impose  constraints  on 
design  choices,  just  as  the  needs  for  interoperability  and  scalability  do. 

The  Internet,  as  a  whole,  has  high  levels  of  interoperability  and  scalability. 
Until  recently,  with  the  advent  of  DNSSEC  and  IPv6,  its  security  has  always  been 
of  lesser  prominence  as  a  design  feature.  The  Internet  is  a  distributed  model,  a 
true  network  of  networks  that  possesses  no  centralized  structure.  All  points  are 
connected  to  all  other  points  through  a  distributed  set  of  routing  tables  and 
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switches.  Consequently,  security  measures  must  be  distributed,  as  well.  In  prac¬ 
tice,  this  means  that  entities  that  are  connected  to  the  network  begin  by  protecting 
themselves  at  the  network  gateway.  In  the  city  planning  model,  network  perimeter 
security  may  be  thought  of  as  the  gates  and  moat  of  a  medieval  town,  while  the 
roads  leading  to  the  town  are  the  common  network  infrastructure.  Depending  on 
the  security  needs  of  the  city’s  occupants,  there  will  be  varying  methods  used 
within  the  city  walls.  The  town’s  bank  and  armory  will  be  heavily  secured  with 
thick  walls  and  guarded  doors,  while  the  individual  residents  may  choose  not  to 
even  lock  their  houses.  The  level  of  security  required  depends  on  risk  profile  and 
cost  structure. 

In  addition  to  these  measures,  the  federal  government  is  currently  engaged 
in  a  major  effort  to  address  cybersecurity,  much  of  which  is  out  of  scope  for  our 
discussion  here.  However,  there  are  several  areas  of  overlap  between  cybersecu¬ 
rity  and  our  work  in  IdM,  for  instance: 

•  Standards-based  interoperability  and  connectivity  across  organiza¬ 
tions  and  data  environments  (see  also  Annex  J); 

•  Research  &  Development  (see  also  section  4.3.1); 

•  Situational  Awareness  -  the  ability  to  continuously  know  the  status 
of  the  security  of  systems  and  their  data  across  broad  architectures 
(see  also  section  5,  recommendation  #6); 

•  Education  &  Outreach  —  The  ability  to  educate  system  designers, 
users,  and  the  public  regarding  the  needs  for  and  benefits  of  IdM; 
at  the  same  time,  the  same  audiences  must  be  made  aware  of  the 
imperatives  to  adhere  to  standards  whenever  possible,  especially 
those  that  support  the  safe  and  secure  handling  of  personal  infor¬ 
mation  (see  also  section  5,  recommendation  #7). 

4.3  S&T  CONSIDERATIONS 

Science  and  Technology  recommendations  are  summarized  below,  in  order  of  pri¬ 
ority  of  the  perceived  need. 
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1 .  Public  Key  Technology.  Public  key  technology,  based  on  asymmetric 
key  encryption,  is  a  robust,  cryptographically  based  IdM  tool  that  has 
the  power  to  provide  strong  identity  authentication/access  control, 
transaction  integrity,  technical  non-repudiation,  and  an  enabler  for  con¬ 
fidentiality.  Its  use  today  is  closely  linked  to  individual  or  group  iden¬ 
tity  and  the  use  of  protective  devices,  such  as  hardware  tokens,  to 
ensure  the  protection  of  the  private  keys. 

While  much  attention  has  been  paid  to  the  infrastructure  that  supports 
generation,  issuance,  and  life  cycle  management  of  the  certificate  ser¬ 
vices  associated  with  public  key  technology,  the  protection  of  the  sys¬ 
tems  and  applications  in  which  the  technology  is  used  have  been  less 
thoroughly  examined.  In  addition,  there  is  the  need  to  explore  public 
key  technology  in  the  context  of  anonymity  —  those  cases  where  an 
individual’s  identity  is  less  important  than  his  or  her  privilege  as  a 
member  of  a  particular  group. 

Finally,  the  effective  extensibility  of  this  technology  to  a  broader 
community  has  yet  to  be  fully  tested.  As  currently  deployed,  public 
key  technology  is  largely  used  by  governments  and  business  entities  in 
closed  finite  systems.  While  interoperability  between  these  systems 
has  been  a  core  activity  of  policy  and  governance  groups  for  the  past 
decade  with  some  level  of  success,  there  is  a  question  concerning  con¬ 
tinued  growth  of  the  infrastructure  and  improving  the  interoperability 
processes  in  order  to  include  unaffiliated  individuals  as  consumers  of 
this  technology. 

As  the  public  key  technology  presence  continues  to  grow,  the  R&D 
needs  can  be  categorized  as  follows: 

•  Identify  the  tools  needed  to  enable  seamless  use  of  public  key  solu¬ 
tions  in  existing  (legacy)  applications  and  systems  with  an  empha¬ 
sis  on  ensuring  the  end  to  end  integrity  of  the  transaction; 
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•  Explore  alternatives  to  hardware  token-based  (smart  card)  security 
for  protecting  cryptographic  keys  associated  with  public  key  tech¬ 
nology,  while  preserving  portability; 

•  Develop  processes  for  the  use  of  public  key  technology  in  protect¬ 
ing  anonymity  while  preserving  authorization/access  con¬ 
trol/transaction  integrity; 

•  Investigate  emerging  capabilities  for  making  public  key  technol¬ 
ogy  more  accessible  and  easier  to  use  by  a  greater  part  of  society; 

•  Investigate  capabilities  for  ensuring  the  enhanced  manageability 
(costs  and  effort  required)  of  public  key  technology  within  and 
across  the  full  scale  (community  size  and  demographics)  and  scope 
(diverse  domains  and  applications)  envisioned  in  this  report; 

•  Explore  advanced  approaches  to  public  key  security  and  architec¬ 
ture  which  could  lead  to  greatly  enhanced  perfonnance  over  time. 

2.  Privacy.  Within  the  context  of  IdM,  preservation  of  privacy  in  a  fed¬ 
eration  of  IdM  systems  is  particularly  important.  Several  entities  are 
involved  in  the  IdM  model  presented  in  this  report:  providers  of  iden¬ 
tity  attributes,  hosts  of  applications  and  the  activity  attributes,  and  enti¬ 
ties  that  provide  or  manage  access  between  the  identity  and  the 
applications  providers.  In  any  given  IdM  implementation,  PII  can  exist 
across  both  the  identity  and  activity  attributes  and  thus  the  entire  envi¬ 
ronment  must  be  analyzed  for  privacy  compliance.  The  challenge  is  to 
build  the  IdM  environment  in  such  a  way  that  minimal  amount  of  iden¬ 
tity  attribute  information  can  be  used  only  when  specifically  needed  by 
an  application,  and  the  overall  creation  and  use  of  PII  can  be  identified 
and  addressed  from  a  privacy  perspective.  Specifically,  there  are  three 
related  R&D  challenges: 

a.  Determine  how  to  tier  identity  attribute  infonnation  used  within  an 
IdM  environment  and  standardize  levels  of  privacy  sensitivity  of 
the  attributes  from  a  single  core  —  perhaps  highly  privacy- 
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sensitive  —  to  a  series  of  other  attributes  that  have  lesser  privacy 
sensitivity.  A  tiered-approach  to  identity  attributes  will  enable  IdM 
implementers  to  view  identity  attributes  along  a  continuum  and  to 
pick  the  appropriate  level  of  identity  infonnation  to  support  the 
particular  application  and,  through  these  choices,  to  minimize  the 
use  of  PII  and  provide  greater  privacy  protections; 

b.  Determine  how  to  tier  the  access  control  environment  to  enable  the 
mechanical  association  of  specific  identity  attributes  from  the  con¬ 
tinuum  of  privacy  sensitivity  described  above  with  the  specific 
needs  of  an  application,  and  potentially  use  that  same  control  me¬ 
chanism  to  govern  infonnation  about  the  application  back  to  the 
identity  attribute  provider; 

c.  Determine  how,  in  a  standardized  way,  to  actually  construct  an 
IdM  implementation  that  aligns  tiered  identity  attributes  and  tiered 
access  control  that  could  regulate  the  level  of  privacy  sensitive 
identity  attribute  infonnation  required  to  support  access  to  a  par¬ 
ticular  element  of  the  application,  and  to  do  so  in  a  federated  IdM 
environment;  he  IdM  implementation  would  enable  control  over 
identity  attributes  to  remain  with  the  identity  provider,  while  con¬ 
trol  over  the  activity  attribute  information  would  remain  with  the 
application  provider  and  thereby  provide  privacy  protection  for  PII 
across  the  entire  federated  environment. 

3.  Digital  Identity  Network  of  Networks.  The  objective  architecture  of 
networked  and  interoperable  digital  identities  described  here  will  re¬ 
quire  the  discovery,  standards  rationalization,  and  integration  of  such 
holdings  across  the  federal  government,  all  while  designing  auditing 
processes  and  security  safeguards  to  guarantee  privacy  in  transaction 
and  data  storage.  At  the  same  time,  specific  data  elements  and  stan¬ 
dards  for  these  must  be  developed  as  required  to  support  digital  identi¬ 
fication.  It  is  important  to  repeat  that  these  must  be  comprised  of 
minimal  common  PII  attributes  to  the  extent  possible.  An  early  exam¬ 
ple  of  the  use  of  data  elements  to  support  digital  identification  is  the 
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Personal  Identity  Card  (PIV)  mandated  by  HSPD-12  and  described  in 
NIST  FIPS  201.  While  this  model  is  appropriate  for  internal  U.S.  gov¬ 
ernment  use,  different  approaches  must  be  pursued  for  enabling  exter¬ 
nal  communities  of  interest.  In  addition  to  developing  a  technical 
approach  for  external  interaction,  research  will  be  required  into  the  so¬ 
cialization  aspects  of  the  identified  solutions. 

4.  Identity  applications  interface.  As  discussed,  the  goal  is  to  permit  po¬ 
tential  designers  and  users  of  applications  to  think  of —  and  treat  — 
the  servicing  IT  backplane  as  a  utility,  whereby  services  are  predict¬ 
able  in  terms  of  availability,  nature,  and  performance.  This  will  require 
that  the  interface  between  end-user  systems,  work  environments,  and 
the  identity-management-support  functions  of  the  core  network  be  de¬ 
fined  in  standardized  tenns.  This  will  lead  to  development  of  applica¬ 
tions  more  sensitive  and  responsive  to  specific  user  requirements, 
while  facilitating  the  safe,  secure,  and  efficient  management  of  ID- 
support  functions  across  the  IT  backplane.  Some  research  is  required 
to  further  define  and  develop  the  technical  specifications  to  permit  ID 
applications  to  “plug  and  play”  into  the  federal  IdM  system  at  multiple 
levels  of  trust,  as  appropriate  to/needed  by  the  application,  via  the 
global  IT  backplane. 

5.  Secure  authentication.  This  is  used  to  identify  entities  that  interact  with 
an  IdM  system.  These  may  include  cryptographic  challenge-response 
protocols,  pass  phrases,  or  biometrics.  R&D  is  needed  to  find  new  me¬ 
thods  of  authentication  or  combinations  of  existing  methods  that  are 
robust  against  attacks,  such  as  password  guessing,  code  cracking,  or 
man-in- the-middle  attacks.  Authentication  methods  should  also  resist 
denial-of-service  attacks  in  which  a  legitimate  entity  can  be  locked  out 
of  an  IdM  system  by  a  malicious  user.  This  research  must  be  applica¬ 
ble  to  implementation  in  supporting  card/token-based,  as  well  as  card¬ 
less,  IdM  authentication  mechanism. 
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6.  Scalable  authentication  mechanisms.  The  end-state  IdM  framework 


will  challenge  traditional  approaches  and  concepts  in  authentication. 
To  prevent  costly  errors  and  lost  time,  research  must  be  conducted  in 
anticipation  of  very  large-scale  IdM  implementations,  with  extensive 
remote  access  capabilities.  Design  features  must  take  into  account  the 
necessity  to  grow  as  the  community  grows  while  maintaining  the  trust 
environment.  Identity  proofing,  enrollment,  life  cycle  management, 
and  other  factors  related  to  operating  a  successful  IdM  system  should 
be  anticipated,  modeled,  and  proven.  In  addition,  the  diverse  nature  or 
scope  of  potential  applications  must  be  anticipated  in  system  and  ar¬ 
chitectural  design,  and  factored  into  designs  for  latency,  system  load¬ 
ing,  and  throughput.  The  end-state  authentication  processes  must  be 
extensible,  adaptive,  and  externally  auditable,  to  ensure  public  trust 
and  system  integrity. 

7.  Biometrics.  This  is  a  topic  that  has  grown  in  significance  in  recent 
years.  In  general,  the  passage  of  time,  plus  dedicated  attention  and 
study,  has  served  to  demystify  this  subject,  while  rationalizing  per- 
formance  claims.  Since  they  do  not  depend  on  either  the  possession 
of  any  physical  object  or  the  memorization  of  detailed  user 
ID/passwords/PINS,  biometrics  may  offer  a  potentially  attractive  op¬ 
tion  to  strongly  authenticate  the  identity  of  persons  who  have  been 
previously  enrolled  in  ID  management  systems  designed  to  use  them. 
However,  the  use  of  biometrics  in  unattended  or  remote  applications  is 
still  a  cause  of  debate  within  the  computer  security  community.  There 
is  much  work  still  to  be  accomplished  in  this  area  to  ensure  biometrics 
are  used  appropriately.  The  two  reference  studies  cited  identify  numer¬ 
ous  R&D  needs  in  this  area,  and  these  are  endorsed  as  written. 


30  Biometrics  have  been  studied  in  some  detail  by  government  in  recent  years.  See  The  National 
Biometrics  Challenge  (http://www.biometrics.gov/Documents/biochallengedoc.pdf);  and  the 
Report  of  the  Defense  Science  Board  Task  Force  on  Biometrics 
(http://www.acq.osd.mil/dsb/reports/2007-Q3-Biometrics.pdf). 
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8.  Federation  with  systems  outside  the  federal  government.  IdM  systems 
used  by  the  government  are  expected  to  interact  with  a  federation  of 
other  systems  used  by  state  and  local  governments,  tribal  administra¬ 
tions,  and  foreign  powers.  To  ensure  privacy  and  security  of  the  gov¬ 
ernment  IdM  systems,  we  must  manage  the  interactions  within  the 
federation  based  on  an  understanding  of  the  policies  and  practices  of 
the  other  systems  with  which  we  are  sharing  trust.  Research  and  de¬ 
velopment  is  needed  on  tools  and  techniques  for  expressing,  compar¬ 
ing,  and  composing  IdM  policies  and  practices  across  these  disparate 
architectures. 

9.  Supply  chain  management.  The  design  and  validation  of  hardware  and 
software  components  of  IT  and  IdM  systems  present  a  serious  area  of 
system  vulnerability  if  not  examined  and  dealt  with.  The  increased  de¬ 
pendence  on  such  systems  in  the  future  will  demand  a  level  of  trust  in 
IdM  systems  that  is  generally  greater  than  our  trust  in  computer  sys¬ 
tems  today.  Research  is  needed  to  develop  mechanisms  to  permit  the 
confident  embrace  of  technology  components  within  IT  and  IdM  ar¬ 
chitectures,  with  minimal  concern  for  insecurity  based  on  the  compo¬ 
nents  themselves  or  their  sources. 

10.  Security  Vulnerability  Analysis.  IT  system  hardware  and  software  in¬ 
teract  with  the  social  network  of  administrators  and  users.  As  systems 
hardware  and  software  design  are  progressively  improved  over  time, 
attackers  will  continue  to  seek  the  softest  point  of  entry  to  penetrate 
and  compromise  critical  processes.  Improved  IdM  processes  can  miti¬ 
gate  many  of  these  vulnerabilities 

1 1 .  Usability.  There  will  clearly  be  more  sponsors,  managers  and  end- 
users  embraced  within  the  future  federal  IdM  system.  Research  is  re¬ 
quired  into  enhancing  ease  of  public  access  and  use  of  these  systems. 
Incorporating  the  principles  of  human  systems  integration  will  endure 
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improved  system  performance  as  well  as  user  understanding  and  utili¬ 
zation. 

4.3.1  Urgency 

The  prioritization  of  R&D  work  related  to  this  report  is  as  indicated  in  the 
numbering  system  used,  with  lower  numbers  denoting  higher  priority  need.  Be¬ 
yond  that,  the  general  speed  with  which  IdM  is  being  deployed  globally  will  de¬ 
mand  urgent  and  sustained  U.S.  federal  attention  to  this  subject.  This  report  seeks 
to  develop  a  comprehensive  picture  of  needs  and  opportunities  related  to  IdM. 
Failure  to  see  the  process  in  the  scope  laid  out  here  will  lead  to  underperformance, 
relative  to  both  achieving  potential  and  meeting  pressing  needs. 

4.3.2  Use  and  Misuse 

Any  attempt  to  compile  a  complete  list  of  the  operational  and  mission  re¬ 
quirements  of  the  entire  federal  government  for  identity-related  applications 
would  be  a  very  extensive  undertaking.  Any  such  list  would  grow  continuously, 
and  as  the  standards,  developmental,  social  and  policy  activities  discussed  here 
advance,  the  pace  of  such  progress  will  only  accelerate. 

Representative  use  cases  from  some  federal  organizations  participating  in 
this  work  can  be  found  at  Annex  I.  Also  in  that  Annex  are  “misuse  cases.”  These 
are  examples  of  behavior  that  should  be  detected,  deterred,  and  prevented  through 
technology  and  policy  efforts. 

4.4  GOVERNMENT-WIDE  COORDINATION 

As  noted  in  Figure  6,  the  objective  IdM  architecture  features  a  management 
framework  wherein  equity  is  distributed  across  every  major  component  of  the 
federal  establishment.  This  is  because  every  organization  will  design,  develop, 
field  and  operate  ID  applications  within  its  own  purview,  with  co-dependency  on 
the  global  grid  and  digital  ID  processes  as  service  providers.  At  the  same  time, 
this  report  has  sought  to  make  the  case  for  the  value  of  standardized  processes  to 
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permit  streamlined  workflow  across  the  federal  enterprise.  Some  of  the  complexi¬ 
ties  and  challenges  associated  with  achieving  these  goals  have  been  identified. 

The  effect  of  this  will  be  a  continuous  need  for  horizontal  interaction  and 
coordination  across  the  federal  interagency  environment.  This  need  will  be  par¬ 
ticularly  acute  in  early  years,  as  the  components  of  the  federal  IdM  are  conceptu¬ 
alized,  designed,  developed,  rolled  out,  and  tested,  eventually  displacing  legacy 
systems  and  procedures. 

Therefore,  an  enduring  IdM  forum  comprised  of  existing  federal  initiatives 
concerned  with  IdM  activities  and  operating  under  the  overall  guidance  of  the 
EOP,  should  be  empowered  to  help  facilitate  the  further  design,  development  and 
use  of  Identity  Management  across  the  federal  enterprise.  This  body  would  coor¬ 
dinate  with  the  individual  efforts  of  the  various  departments  and  agencies,  as  these 
seek  to  enhance  their  own  systems  and  capabilities  in  this  area,  identifying  gaps 
across  these  existing  activities  and  work  to  overcome  those  gaps.  The  interagency 
focus  would  emphasize:  cross-organizational  interoperability  and  architecture; 
development  and  adoption  of  standards;  use  guidelines;  and  development  of  con¬ 
sistent  legal  and  policy  approaches  to  IdM  across  the  federal  government  in  the 
performance  of  all  of  its  missions. 
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Representative  Federal  IdM  Coordination  efforts  include: 

•  Federal  CIO  Council,  under  whose  leadership  the  following  activities  are 
chartered: 

o  Federal  Enterprise  Architecture  Committee 
o  Federal  Identity  Credentialing  Committee 
o  Federal  PKI  Policy  Authority 

•  Committee  for  National  Security  Systems 

•  NSTC  Subcommittee  on  Biometrics  and  Identity  Management 

•  Information  Sharing  Environment  (ISE)  Identity  and  Access 
Management  Initiative 

•  President’s  Identity  Theft  Task  Force 

•  Terrorist  Screening  Center 

•  ODNI  Interagency  Identity  Intelligence  Task  Force 
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Annex  A  Task  Force  Charter 


CHARTER 

of  the 

TASK  FORCE  ON  IDM 

SUBCOMMITTEE  ON  BIOMETRICS 

AND  IDM 

COMMITTEE  ON  TECHNOLOGY 

NATIONAL  SCIENCE  AND  TECHNOLOGY  COUNCIL 

A.  Official  Designation 

The  Task  Force  on  IdM  (TF)  is  hereby  established  by  action  of  the  Subcommittee  on 
Biometrics  and  IdM  (Subcommittee)  of  the  Committee  on  Technology  (COT)  in  the  National  Sci¬ 
ence  and  Technology  Council  (NSTC). 

B.  Background 

In  recent  years,  electronic  identities  have  proliferated  rapidly,  playing  a  key  role  in  com¬ 
merce,  security,  and  many  other  aspects  of  today's  highly  connected  mobile  world.  This  change 
has  been  accompanied  by  an  increased  need  to  ensure  high-confidence  identification  of  specific 
individuals,  giving  rise  to  the  confluence  of  biometrics  and  “IdM”  (IdM). 

Numerous  IdM  technologies,  standards  and  related  plans  are  being  developed  independ¬ 
ently  at  the  application  and  sector-specific  levels  (such  as  telecommunications,  border  security, 
financial  services,  identity  theft,  etc.).  While  these  all  positively  contribute  to  advancing  IdM,  the 
technology  and  its  potential  benefits  will  be  limited  without  cross-sector  and  cross-application 
coordination  and  a  common  technological  foundation.  At  the  federal  level,  needs  and  uses  vary 
significantly,  and  a  one-size-fits-all  technical  IdM  architecture  cannot  satisfy  all  agency  con¬ 
straints  and  requirements.  However,  there  are  clear  commonalities  that  would  benefit  from  a  coor¬ 
dinated  federal  effort,  enhance  agencies’  abilities  to  meet  mission  needs,  ensure  privacy 
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protection,  and  enable  individuals  to  exercise  their  identities  securely.  In  recognition  of  these  chal¬ 
lenges,  the  Subcommittee's  mission  was  expanded  in  2007  to  include  coordination  of  federal  IdM 
activities. 

C.  Purpose  and  Scope 

The  purpose  of  the  TF  is  to  assess  the  status  of  and  challenges  related  to  IdM  technolo¬ 
gies  and  develop  recommendations  regarding  the  federal  government’s  science  and  technology 
needs  in  this  area. 


For  the  purposes  of  this  Task  Force,  “IdM”  means  “the  combination  of  technical  systems, 
mles  and  procedures  that  define  the  ownership,  utilization,  and  safeguard  of  personal  identity  in¬ 
formation.  The  primary  goal  of  the  IdM  process  is  to  assign  attributes  to  a  digital  identity  and  to 
connect  that  identity  to  an  individual.” 

D.  Tasks 

The  TF  serves  as  part  of  the  internal  deliberative  process  of  the  NSTC.  Reporting  to  and 
directed  by  the  Subcommittee,  the  TF  shall: 

•  Inventory  and  Baseline  IdM  Activities,  Applications,  and  Challenges. 

•  Gather  existing  IdM-related  information  (such  as  documented  needs,  business 
cases,  definitions,  standards,  plans,  etc.)  from  programs/sectors  of  interest; 

•  Review  disparate  IdM  taxonomies  across  the  federal  government,  and  establish 
a  common  cross-sector  taxonomy  for  standard  usage; 

•  Inventory  ongoing  and  upcoming  federal  IdM  programs  to  establish  a  current 
baseline  of  activities  and  needs,  within  the  context  of  the  common  taxonomy 
described  above; 

•  Perform  an  initial  review  of  federal,  national,  and  international  IdM  standards 
activities,  including  intra-governmental  coordination  between  the  various 
centers  of  standards  management  and  authority; 

•  Identify  activities  that  warrant  federal  coordination. 

•  Identify  critical  IdM  issues  that  require  immediate  attention  and  action. 

•  Identify  issues  that  require  long-term  coordination,  for  example: 

•  RDT&E  (technology-specific,  and  in  general) 

•  Standards  Development  and  Adoption 

•  International  and  public-sector  liaison 

•  Outreach/Communications 

•  Develop  recommendations  for  Subcommittee  consideration. 

•  Recommend  changes  to  the  Subcommittee’s  organizational  structure  to  support 
necessary  IdM  tasks; 

•  Propose  a  plan  for  the  Subcommittee’s  subsequent  IdM  work; 
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Identify  necessary  tasks  that  are  beyond  the  subcommittee’s  purview  and  the 
groups  best  suited  to  address  them. 


E.  Membership 

The  co-chairs  of  the  Subcommittee,  working  with  the  Subcommittee’s  existing  Depart¬ 
ment  Leads,  will  identify  participants  in  the  TF.  The  following  NSTC  departments  and  agencies 
shall  be  represented  on  the  TF: 

Department  of  Commerce 

Department  of  Defense 

Department  of  Energy 

Department  of  Health  and  Human  Services 

Department  of  Homeland  Security 

Department  of  Justice 

Department  of  State 

Department  of  Transportation 

Department  of  Treasury 

Department  of  Veterans  Affairs 

General  Services  Administration 

National  Science  Foundation 

Federal  Trade  Commission 

The  following  organizations  in  the  Executive  Office  of  the  President  may  also  be  repre¬ 
sented  on  the  Subcommittee: 

Office  of  Management  and  Budget 
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Office  of  Science  and  Technology  Policy 


The  Subcommittee  co-chairs  may,  from  time  to  time,  designate  additional  representation 
from  other  executive  organizations,  departments,  and  agencies. 

The  TF,  upon  receiving  approval  from  the  Office  of  Science  and  Technology  Policy,  may 
utilize  the  Science  and  Technology  Policy  Institute  to  provide  assistance  in  meeting  these  tasks. 

F.  Private  Sector  Interface 

The  TF  may  seek  advice  from  members  of  the  President’s  Council  of  Advisors  on  Sci¬ 
ence  and  Technology  and  will  recommend  to  the  Director,  Office  of  Science  and  Technology  Pol¬ 
icy,  the  nature  of  additional  private  sector  advice  needed  to  accomplish  its  mission.  The  TF  may 
also  interact  with  and  receive  ad  hoc  advice  from  various  private-sector  groups  as  consistent  with 
the  Federal  Advisory  Committee  Act. 

G.  Termination  Date 

Unless  renewed  by  the  Subcommittee  co-chairs  prior  to  its  expiration,  the  TF  shall  termi¬ 
nate  on  July  1,  2008. 

H.  Determination 

1  hereby  determine  that  the  formation  of  the  Task  Force  on  IdM  is  in  the  public  interest  in 
connection  with  the  performance  of  duties  imposed  on  the  Executive  Branch  by  law,  and  that  such 
duties  can  best  be  performed  through  the  advice  and  counsel  of  such  a  group. 

Final  signature/date:  8  January  2008 
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Annex  B  Task  Force  Composition 

Task  Force  Co-Chairs: 

Duane  Blackburn,  OS  TP 
James  Dray,  NIST 
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Team  Leads: 

Bill  Brykczynski,  STPI 
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Task  Force  Members: 
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Annex  C  Presentations  to  the  Identity  Management  Task 
Force 


Date 

Title 

Presenter 

Jan  24,  2008 

Identity  Management  at 

USD  A 

Owen  Unangst,  USD  A 

Jan  31,  2008 

Claims  Will  Change 
Everything 

Kim  Cameron,  Micro¬ 
soft 

Feb  7,  2008 

Scope 

Jim  Dray,  NIST 

Feb  14,  2008 

HSPD-12,  Fed  PKI,  e- 

Authentication 

Judith  Spencer,  GSA 

Feb  28,  2008 

Who  Goes  There? 

Stephen  Holden,  CSTB, 
University  of  Md 

Mar  20,  2008 

Identity  Mgmt  Issues  & 
Challenges 

Richard  Brackney,  NSA 

Mar  27,  2008 

Identity  Management 

Mark  Clancy,  Citigroup 

Apr  3,  2008 

Vision  of  Id  Manage¬ 
ment  End  State 

William  Gravell,  DOD 

Apr  24,  2008 

Privacy  Act  Overview 

Kristen  Moncada,  DOJ 

May  8,  2008 

REAL  ID 

Selden  Biggs,  DHS 

May  22,  2008 

Cyber  Security 

Charles  Romine,  OSTP 
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Annex  D  Department  of  Defense  (DOD)  Global  Information 
Grid  (GIG) 

The  DOD  GIG  is  a  globally  interconnected,  end-to-end  set  of  information 
capabilities,  associated  processes,  and  personnel  for  collecting,  processing,  stor¬ 
ing,  securing,  discovering,  disseminating  and  managing  information  on  demand  to 
all  DOD  employees  and  contractor  support  personnel.  Another  set  of  users  belong 
to  family  members  and  retirees  who  require  access  to  financial  and  medical  re¬ 
sources.  Other  potential  users  are  federal  government  personnel  as  well  as  coali¬ 
tion  and  allied  members. 
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Figure  D-l.  The  DOD  Global  Information  Grid 
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As  the  DOD  moves  toward  a  Network-Centric  operational  environment 
with  a  goal  of  Information  Superiority,  it  is  becoming  increasingly  dependent  on  a 
secure  and  interoperable  GIG.  This  dependence  puts  the  Department  at  greater 
risk.  The  threats  against  DOD’s  Information  Environment  are  asymmetric  and  the 
actors,  methods,  and  tools  can  be  very  different  but  still  have  the  same  conse¬ 
quence.  The  threats  against  the  people,  processes  and  technologies  can  be  both 
cyber  as  well  as  physical.  A  strong  and  resilient  Identity  and  Privilege  Manage¬ 
ment  system  is  critical  to  carrying  out  security  responsibilities. 

The  DOD  GIG  supports  several  domains  —  the  DOD,  National  Security, 
and  related  Intelligence  Community  missions  and  business  functions,  in  war  and 
in  peace.  It  provides  worldwide  capabilities  from  all  operating  locations  to  all  cat¬ 
egories  of  users  and  supports  interfaces  to  coalition,  allied,  and  non-DOD  users 
and  systems.  There  are  established  GIG  compliance  and  enforcement  mechanisms 
to  achieve  IT  and  National  Security  Systems  (NSS)  interoperability,  and  Informa¬ 
tion  Assurance  (IA).  The  DOD  has  developed  I A  standards  and  conventions  in 
support  of  the  GIG  in  coordination  with  the  NIST.  Lastly,  all  DOD  Component- 
leased,  -owned,  -operated,  or  -managed  GIG  systems,  services,  upgrades,  or  ex¬ 
pansions  to  existing  systems  or  services  are  acquired  or  procured  in  compliance 
with  the  Department’s  Planning,  Programming  and  Budgeting  System  and  support 
a  systems  of  systems  concept  capability  in  an  interoperable,  standards-based  en¬ 
terprise. 

The  demands  for  information  sharing  and  a  global  enterprise  available  to 
users  requires  effective  infonnation  protection  measures  in  place  to  control  access 
to  authorized  users  while  preventing  access  to  unauthorized  users.  The  enterprise 
requires  trust  and  confidence  in  the  identity  of  initiators  and  recipients  of  the  re¬ 
quested  information,  and,  finally,  that  the  infonnation  is  trustworthy  with  a  high 
degree  of  certitude.  At  the  heart  of  it  all  is  a  robust  IdM  system  with  its  ability  to 
collect,  identify,  store,  discover,  retrieve  and  share  identity  data  securely  across 
the  DOD  GIG  to  a  multitude  of  consumers  while  protecting  PII  from  compromise 
and  identity  theft.  The  DOD  continues  to  use  technology  as  enablers  (e.g,  Public 
Key  and  Biometrics)  in  support  of  IdM  in  order  to  provide  higher  levels  of  certi- 
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tude  about  individuals,  friendly,  neutral  or  adversary,  across  the  full  range  of  mili¬ 
tary  operations  and  DOD  business  functions. 

The  DOD  uses  Public  Key  (PK)  technology  as  part  of  its  IdM  Framework. 
Public  key  cryptography  is  a  critical  element  of  the  DOD  net-centric  goals  in  pro¬ 
viding  for  identification,  integrity,  authenticity,  confidentiality,  and  non¬ 
repudiation  services.  The  public  key  component  provides  electronic  credentials 
that  are  unique,  un-forgeable,  and  trusted  for  use  in  virtual  network  transactions, 
and  supports  strong  authentication  for  a  broad  range  of  human  and  non-person 
entities  (devices)  requesting  access  to  DOD  networks,  information  and  resources. 
The  PK-based  authentication  provides  the  ability  to  log  on  to  network  or  Web- 
based  resources,  thus  eliminating  the  inherent  vulnerabilities  of  user 
ID/password/PIN.  Although  there  are  6  million  probes  of  DOD  networks  a  day, 
successful  intrusions  have  declined  46  percent  in  the  past  year  because  of  the 
requirement  that  all  DOD  personnel  log  on  to  unclassified  networks  using  a 
smartcard  with  their  PK  certificate. 

A  PKI  provides  a  secure  infrastructure  and  common  standards  for  identity 
proofing,  credential  issuance  and  revocation  management.  It  is  the  framework  and 
services  that  provide  for  generation,  production,  distribution,  control,  accounting 
and  destruction  of  public  key  certificates.  PKI  provides  IA  capabilities,  issuing 
and  managing  virtual  identities  and  associated  credentials  and  key  materials  for 
users,  applications,  servers,  and  network  components.  The  PKI  provides  a  founda¬ 
tion  for  interoperable  security  services  including  authentication,  data  integrity, 
and  confidentiality,  and  also  supports  digital  signature,  access  control  and  non¬ 
repudiation.  PKI  can  be  used  to  facilitate  broader  usage  for  network  logon,  e-mail 
signing,  and  certificate-based  authentication  for  Web  servers.  PKI  offers  net- 
centric  services  for  users  to  manage  their  credentials  and  for  applications  to  au¬ 
thenticate  certificates  received  during  electronic  transactions.  It  can  provide  the 
security  foundation  for  assured  infonnation  sharing  across  a  wide  range  of  mis- 


33  Lt  Gen  Croom,  Director  DISA,  remarks  at  AFCEA  SpaceComm  2007  Conference 
(http://www.fcw.com/online/news/97480-l.html) 
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sion  and  business  functions.  The  vast  number  of  organizations  beginning  to  use 
PKI  makes  it  scalable  for  interactions  on  a  global  basis. 

The  DOD  Biometrics  Enterprise  is  an  entity  comprised  of  the 
Department’s  joint,  service,  and  agency  organizations  working  together  to 
integrate  biometrics  into  the  identity  transactions  needed  to  support  military 
operations  and  departmental  business  functions.  It  is  a  flexible,  global  biometrics 
enterprise  that  protects  rights  and  enables  services  for  friends  and  partners,  and 
denies  anonymity  to  adversaries.  It  is  a  global  enterprise  with  accurate  collection, 
rapid  data  enrollment  and  storage,  reliable  matching  through  multimodal  fusion, 
real-time  reach-back  access,  and  timely  reply  to  meet  the  needs  of  the  DOD  bio¬ 
metrics  customer  anytime,  anywhere.  The  Enterprise  shares  biometrics  data  with 
internal,  interagency,  and  foreign  partners  in  accordance  with  law  and  policy.  It 
protects  biometrics  data  from  unauthorized  access,  misuse,  corruption,  and  theft 
and  ensures  that  the  privacy  rights  of  U.S.  citizens  and  allies  are  protected.  The 
Enterprise  also  incorporates  biometrics  data  into  DOD,  intelligence  community, 
and  interagency  activities.  A  biometrics-enabled  identity  is  used  to  monitor  indi¬ 
vidual  access  privileges  to  DOD  services  and  resources,  or  to  deny  a  criminal  or 
adversary  the  ability  to  hide  his  true  identity  by  stripping  away  anonymity  with 
swift,  accurate,  and  definitive  identity  verification.  Stripping  away  the  anonymity 
of  adversaries  and  verifying  identities  are  national  security  interests  of  the  highest 
order.  The  Biometrics  Enterprise  is  a  standards-based  IdM  service.  Standardiza¬ 
tion  permits  access  and  interoperable  sharing  by  all  functional  processes  while,  at 
the  same  time,  preserving  the  underlying  integrity  of  the  IdM  service  data.  Inher¬ 
ent  in  the  Enterprise’s  ability  to  enhance  and  enable  DOD  business  functions  is 
the  absolute  assurance  that  the  data  is  secure  and  the  privacy  of  the  Total  Force 
and  the  Department’s  allies  and  partners  are  preserved. 
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Annex  E  Goals  and  Objectives  for  Achieving  the  Objective  Fed¬ 
eral  IdM  System 

Goal  #1  Deploy  and  Operate  an  IdM  Framework  Across  the 

federal  government 

The  IdM  plan  must  realize  a  capability  consistent  with  the  long-term  vi¬ 
sion,  which  can  support  all  entities  from  users  to  devices  to  systems,  physical  and 
logical  access.  The  IdM  capability  must  be  flexible,  agile,  dynamic  and  scalable  to 
account  for  and  respond  to  the  numerous  changes  in  most  organizations  and  mis¬ 
sion  operations.  The  need  for  higher  levels  of  confidence  in  claimed  identities  and 
the  safeguarding  of  data  associated  with  identities  of  people,  systems,  processes 
and  organizations  underline  the  demand  for  continued  IdM  evolution.  Enterprise 
services  can  be  focused  deployments,  but  the  local  entities  (e.g.,  humans,  sponsors 
of  devices  and  owners  of  business  applications)  will  have  to  be  registered,  issued 
credentials,  and  systems  configured  to  use  those  services.  This  requires  coordi¬ 
nated  efforts,  standards-based  implementations,  synchronized  execution  and  a  se¬ 
cure  IT  infrastructure  to  support  a  global,  interoperable  capability  described 
below.  It  is  acknowledged  that  existing  activity  in  developing  an  IdM  framework 
is  underway  within  the  federal  government.  The  goal  is  to  take  the  current  activity 
forward  by  combining  the  different  efforts  being  undertaken  by  different  sectors. 

Objective  1.1  Establish  a  Robust  IdM  framework  for  the  Global  Tele¬ 
communications  Grid.  The  Global  Grid  supporting  the  IdM  system  must  be  ro¬ 
bust  —  that  is,  it  must  provide  adequate  assurance  and  resilience  to  cyber  attack 
to  prevent  compromise  of  the  system  and  exploitation  of  the  ID  data.  A  successful 
IdM  system  will  also  be  required  to  support  a  wide  variety  of  privacy  and  security 
levels,  ranging  from  low-security  password-based  single-factor  authentication  to 
high-end  attribute-based  systems  employing  state  of  the  art  privacy-enhancing 
techniques.  Technical  aspects  of  this  problem  can  be  addressed  conceptually  by 
designing  an  appropriate  IdM  framework. 

The  IdM  framework  should: 
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•  Associate  people  and  devices  with  an  identity  (PKI,  biometric, 
other).  This  identity  will  be  used  to  access  facilities  and  networks; 

•  Use  shared  standards,  protocols  and  infrastructure  to  support  both 
logical  and  physical  access  to  resources; 

•  Use  a  federated  approach.  It  will  recognize  approved  credentials 
from  industry,  government  and  foreign  partners; 

•  Marry  identity  information  with  attributes  associated  with  an  entity 
to  facilitate  access  to  facilities  and  resources; 

•  Create  authoritative  sources  to  house  and  maintain  attribute-related 
information  on  people  and  devices. 


Goal  #2  Leverage  the  Success  of  Ongoing  IdM  Investments 

Many  agencies  in  the  federal  government  have  made  significant  progress 
in  the  deployment  and  operation  of  IdM  capabilities.  These  investments  require 
full  life  cycle  support,  and,  in  many  cases,  have  to  incorporate  enhancements 
(e.g.,  extended  support  for  security  and  interoperability  with  an  expanded  set  of 
external  partners)  to  retain  their  utility. 

Objective  2.1.  Execute  Ongoing  IdM  Programs  —  There  are  several 
key  programs  and  initiatives  among  the  different  agencies  that  represent  signifi¬ 
cant  investment  and  have  to  be  leveraged.  Each  focuses  on  a  specific  aspect  of 
IdM  (e.g.,  PIV  Card,  PKI,  identity  issuance,  biometrics,  and  attributes)  and  deliv¬ 
ers  operational  capabilities  that  are  integral  to  a  comprehensive  and  secure  IdM 
service  within  their  respective  agencies.  They  can  provide  identity  determinations 
to  higher  levels  of  certainty.  These  activities  must  continue  to  be  funded  and  exe¬ 
cuted. 


Objective  2.2.  Align  and  Execute  IdM  Initiatives  —  Since  these  initia¬ 
tives  have  many  complex  interrelationships,  it  may  be  necessary  to  identify  and 
implement  adjustments  that  ensure  technical  integration  and  alignment  to  deliver 
true  operational  improvements  while  providing  for  interoperability  across  the 
agencies. 
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Goal  #3 


Implement  Additional  IdM  Initiatives 


The  evolution  of  IdM  has  to  extend  capabilities  beyond  those  addressed  in 
ongoing  investments.  As  with  the  ongoing  efforts,  these  have  to  be  planned  and 
executed  to  enable  integration  and  synchronization. 

Objective  3.1.  Develop  an  Overarching  IdM  Framework  —  Any  im¬ 
plementation  this  broad  in  scale  and  magnitude  will  have  to  be  implemented  over 
time  to  leverage  various  technologies  and  user  circumstances.  To  ensure  that  the 
evolution  leads  to  the  desired  result,  the  federal  government  will  have  to  establish 
and  ratify  a  technical  framework  that  defines  the  functionality,  performance,  inter¬ 
faces,  and  associated  standards  and  specifications  needed  to  guide  each  initiative. 

Objective  3.2.  Implement  Additional  IdM  Capabilities  —  Since  there 
will  be  additional  capabilities  that  may  be  needed  to  reach  the  IdM  vision,  it  will 
be  necessary  to  find  a  means  for  their  implementation.  These  could  be  structured 
as  enhanced  functionality  within  ongoing  programs  or  as  new  initiatives.  In  either 
case,  these  capabilities  will  have  to  be  engineered  and  integrated  into  the  broader 
IdM  fabric. 

Objective  3.3.  HSPD-12/FIPS  201-1.  —  With  the  issuance  of  Homeland 
Security  Presidential  Directive  12  (HSPD-12)  and  the  subsequent  release  of  FIPS 
201-1  by  NIST,  there  was  a  significant  move  away  from  the  silo  approach  toward 
interoperability.  FIPS  201-1  mandates  common  standards  for  the  identity  proofing 
of  all  federal  employees  and  all  contractors  working  for  the  federal  government. 

The  mandated  standards  of  the  PIV  card  systems  and  the  use  of  newer 
technologies  in  their  development  has  created  an  opportunity  to  build  on  the  new 
systems.  Within  the  federal  government,  the  PIV  card  is  a  new  opportunity  that 
should  be  leveraged  as  the  basis  for  enhanced  functionality  and  can  be  used  as  a 
model  for  the  development  of  other  systems  that  need  to  share  data  across  agen¬ 
cies. 


Goal  #4  Federate  IdM  to  Enable  Operations  with  Partners 
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The  IdM  framework  must  consider  the  concept  of  External  Access  Points 
that  will  provide  the  connection  and  the  functions  necessary  for  two  federated  en¬ 
terprises  to  support  transactions  across  the  interface.  Each  agency  in  the  federal 
government  operations  will  rely  on  collaboration  and  knowledge  sharing  with 
other  agencies  to  include  the  intelligence  community,  state/local/tribal  govern¬ 
ments,  industry,  allies  and  coalition  partners,  and  foreign  governments  in  order  to 
conduct  business.  This  demands  a  trust  framework  among  the  various  players  and 
an  IdM  capability  to  support  this  scope  of  interoperation.  It  must  also  be  noted 
that  by  nature  of  their  missions,  some  federal  agencies  must  be  able  to  selectively 
interoperate,  allowing  some  access  to  systems  and  data  while  denying  that  access 
to  others.  Future  federations  must  acknowledge  and  incorporate  the  trust  frame¬ 
work  into  their  solutions. 

Objective  4.1  Enhance  the  Emerging  IdM  Federation.  —  A  federation 
is  a  collection  of  organizations,  requiring  a  formal  governance  structure  to  be  es¬ 
tablished,  with  each  member  agreeing  to  adhere  to  a  set  of  standards  and  policies 
that  enable  the  execution  and  operation  of  a  common  IdM  system  within  each  or¬ 
ganization.  A  secure  and  interoperable  IdM  system  is  an  important  objective  for 
the  federal  government,  as  identity  credentials  must  cross  agency  networks,  as 
well  as  their  applications.  Through  the  use  of  electronic  identity  credentials,  or¬ 
ganizations  can  establish  trust  relationships  among  the  agencies’  unique  IdM  sys¬ 
tems.  To  accomplish  this  objective,  the  IdM  Federation  must  leverage  identity 
credentials  across  multiple  trust  environments  and  enable  identity  assurance  ser¬ 
vices  for  federal  electronic  business  processes,  which  will  enable  trust  and  confi¬ 
dence  in  government  transactions  through  the  establishment  of  an  integrated 
policy  and  technical  infrastructure  for  identity  management.  Governance  and 
compliance  with  assurance  level  policy,  technical  standards  for  connectivity,  con¬ 
tent  and  security  management  will  be  critical  to  solving  the  technical  interopera¬ 
bility  challenges. 

From  the  perspective  of  users  and  operators,  an  envisioned  IdM  Federation  will 
operate  seamlessly  and  transparently  with  its  counterparts  in  external  partner  envi¬ 
ronments.  Operations  with  these  partners  will  be  driven  by  policies,  supported  by 
operational  procedures,  and  safeguarded  with  technical  enforcement  mechanisms 
to  control  the  ability  to  interact  with  them  and  allow  access  to  resources.  In  addi- 
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tion  to  policies,  there  are  legal  and  regulatory  restrictions  on  various  aspects  of 
IdM  functionality. 

Objective  4.2.  Develop  Federation  Guidelines  —  While  implementa¬ 
tions  are  focused  on  the  use  of  commercial  standards,  extending  operations  re¬ 
quires  a  strategy  that  allows  each  member  organization  the  prerogative  to  control 
its  own  implementation  and  still  enable  a  means  for  interoperation.  From  the  per¬ 
spective  of  users,  the  envisioned  IdM  Federation  will  operate  seamlessly  and 
transparently  in  external  partner  environments. 

Goal  #5  Align  IdM  Governance,  Policy  and  Guidance 

Every  federal  government  department  and  agency  has  an  expansive  set  of 
written  policies  concerning  identity  management  and  access  control.  Over  time,  a 
divergence  has  materialized  due  to  the  local  development  of  procedures  and  the 
differing  interpretations  of  the  various  organizations.  As  a  result,  agencies  are  rec¬ 
ognizing  the  importance  of  having  comprehensive,  community-wide  policies  that 
can  be  implemented  with  a  common  set  of  procedures  across  the  IdM  enterprise. 
The  IA  and  IdM  policies  currently  in  use  should  be  reviewed,  with  the  goal  of  re¬ 
freshing  and  aligning  them  to  ensure  consistency  as  the  next  generation  IdM 
framework  is  developed.  Governance  of  this  activity  rests  with  the  Federal  CIO 
Council,  comprised  of  the  Chief  Information  Officers  of  all  cabinet-level  depart¬ 
ments  and  other  independent  agencies. 
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Annex  F  Roadmap  for  Developing  the  Standards  in  Global 
Standards  Organizations  that  are  Necessary  to  Achieve 
a  Global  IdM  system 

This  annex  elaborates  on  the  work  that  needs  to  be  done  in  the  standards 
development  area  in  order  to  achieve  the  vision  of  the  global  IdM  framework  that 
is  described  in  the  main  body  of  this  report,  of  which  the  federal  IdM  would  be  an 
integral  component. 

In  order  to  achieve  a  global  IdM  system,  global  standards  will  need  to  be 
developed  with  respect  to  the  three  major  functions  performed:  management, 
bridging,  and  identity. 

The  federal  government  needs  to  be  involved  in  these  standardization 
processes  in  order  to  ensure  that  the  global  standards  that  are  developed  can  sup¬ 
port  federal  requirements  (e.g.,  for  priority  communications  in  emergency  situa¬ 
tions)  and  policies  (e.g.,  privacy  policies). 

Objective  1.  Develop  global  standards  for  managing  an  IDM  frame¬ 
work  —  The  management  function  of  a  successful  IDM  framework  addresses  the 
crucial  functions  of  secure  life  cycle  maintenance  of  data  as  identities  are  estab¬ 
lished,  proofed,  modified,  suspended,  tenninated,  archived,  or  reallocated.  In  or¬ 
der  for  a  global  IdM  system  t  be  successful  the  requirements  and  processes  for 
each  of  these  life  cycle  events  must  be  agreed  by  all  participants  in  the  global 
community.  The  ability  to  trust  globally  is  directly  impacted  by  the  confidence 
each  participating  IdM  places  in  the  life  cycle  management  of  the  others.  Three 
models  of  the  management  function  have  been  identified,  depending  on  whether 
the  identity  data  is  controlled  by  a  network  (the  network-centric  model),  a  user 
(the  user-centric  model,  where  the  users  have  a  role  to  play  in  managing  the  data 
about  them  that  resides  in  a  data  source),  or  a  service  provider  (the  service-centric 
model).  The  management  function  for  each  identity  management  system  includes 
access  control  mechanisms  such  as  authentication,  authorization,  and  auditing  of 
managers  and  users  as  well  as  possible  user  certification  by  a  third  party  for  that 
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individual  IdM  system  or  federation  of  systems.  Security  assurance  is  part  of  the 
access  control  mechanism. 

The  management  function  for  an  IdM  system  is  depicted  within  the  blue 
boxes  in  Figure  F-l  below.  These  boxes  represent  different  IdM  systems  or  fed¬ 
erations  of  systems.  A  party  (the  “relying  party”)  within  System  A  wants  to  vali¬ 
date  the  identity  of  some  entity  with  whom  the  relying  party  wants  to  enter  into  a 
transaction.  The  relying  party  seeks  to  validate  the  identity  of  that  entity  by  re¬ 
questing  assistance  from  an  identity  provider.  The  identity  provider  may  be  able 
to  find  the  identity  infonnation  within  System  A,  in  which  case  it  needs  to  pass 
through  an  access  control  process  to  establish  it  meets  the  requisite  security  pro¬ 
file  and  is  entitled  to  obtain  the  data  from  the  data  repository.  (If  the  identity  in¬ 
formation  is  not  in  System  A,  the  information  provider  will  have  to  ’’discover”  the 
necessary  identity  information  by  going  outside  System  A,  using  a  bridging  func¬ 
tion  involving  a  data  model  to  find  some  other  IdM  system  (System  B)  that  has 
the  requisite  infonnation  and  communicate  with  it.) 

The  data  model  acts  as  a  trusted  technical  intennediary;  it  can  map  or 
translate  all  relevant  identity  data  structures  into  a  common  data  structure. 

Objective  2.  Develop  global  standards  for  the  bridging  function  of  an 
IDM  framework.  The  objective  of  the  bridging  function  in  an  IdM  framework  is 
to  bridge  the  differences  between  disparate  identity  management  systems  or  fed¬ 
erations  of  systems.  To  be  successful,  a  bridging  function  must  enable  a  wide  va¬ 
riety  of  requests  for  identity  information  to  be  mapped  against  a  wide  variety  of 
identity  data  repositories  across  different  trust  domains.34  A  successful  IDM 
framework  must  be  sufficiently  flexible  and  technologically  neutral  to  support 


34  A  trust  domain  is  the  area  defined  by  the  boundaries  of  a  federation,  where  all  elements  are  un¬ 
der  the  control  of  owners  who  have  defined  the  limits  and  mechanisms  for  achieving  trust  and 
have  agreed  to  implement  them.  A  trust  domain  in  the  IdM  context  would  consist  of  those 
identity  providers,  relying  parties,  and  perhaps  end-users  who  have  already  agreed  to  a  collec¬ 
tion  of  usage  and  maintenance  policies. 
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different  situations  and  types  of  identity  management  infrastructures,  and  to  sup¬ 
port  the  multitude  of  existing  and  emerging  identity  management  systems. 

The  bridging  function  of  an  IdM  framework  is  depicted  in  Figure  F-l.  The 
figure  shows  two  IdM  systems  (or  federations  of  systems)  that  are  unrelated  to 
each  other  and  do  not  share  the  same  data  fonnats.  In  this  case,  a  data  requestor 
(an  identity  provider)  in  System  A,  upon  discovering  that  desired  identity  data  re¬ 
sides  in  a  data  source  in  some  System  B  with  which  it  has  no  relationship,  sends 
the  request  through  a  bridge  involving  an  identity  data  model.  At  the  front  end  of 
the  bridge  is  the  relevant  access  profile  that  authenticates  the  requestor  and  ap¬ 
plies  security  and  other  policies  to  authorize  the  transaction.  The  access  profile 
translates  the  request  into  the  universal  standard  language  of  the  data  model,  un¬ 
derstood  by  all  profiles,  and  forwards  the  request  to  the  relevant  data  profile, 
which  translates  it  from  the  globally  standardized  language  of  the  data  model  to  a 
format  that  the  discovered  data  source  can  understand.  The  data  source  provides 
the  required  data,  following  the  same  process  in  reverse.  This  two-step  translation 
process  simplifies  the  translation  capability  set  required  by  any  single  profile. 
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The  Bridging  and  Management  Functions 
in  an  Idm  Metaframework 
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Figure  F-l.  The  Bridging  and  Management  Functions  in  an  IdM  framework 


Objective  3.  Develop  global  standards  for  the  identity  function  of  an 
IDM  framework.  —  The  third  major  aspect  of  the  IdM  framework  is  the  identity 
function.  In  contrast  to  the  bridging  function,  which  addresses  interworking  hori¬ 
zontally  across  different  systems  and  federations  of  systems,  the  identity  function 
addresses  vertical  consistency  between  the  identity  data  used  in  the  different  net¬ 
work  application,  service  and  transport  levels.  Standards  need  to  be  developed  to 
serve  the  identity  needs  all  three  stratums  consistently. 


Objective  4.  Develop  federal  requirements  and  policies  that  the  U.S. 
wants  to  have  reflected  in  the  development  of  global  standards.  —  The  design 
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of  specific  standards  for  the  IDM  framework  will  depend  heavily  on  the  require¬ 
ments  and  policies  that  it  must  meet.  The  federal  government  has  an  important 
role  to  play  in  identifying  the  requirements  and  policies  that  global  technical  stan¬ 
dards  need  to  support. 

Policies  and  requirements  determine  how  trust  is  defined  and  established 
(e.g.,  what  information  will  be  revealed,  to  which  parties,  for  which  purposes,  and 
how  it  is  to  be  treated).  Standards  development  organizations  do  not  develop  poli¬ 
cies  and  requirements.  However,  standards-setting  bodies  must  develop  technical 
solutions  that  can  accommodate  the  entire  range  of  non-technical  policies  and  re¬ 
quirements  that  governments  and  businesses  develop.  Governments  and  regional 
groups  establish  some  policies  and  requirements,  such  as  for  privacy  and  compli¬ 
ance.  Businesses  establish  other  policies  and  requirements,  such  as  for  the  protec¬ 
tion  of  proprietary  information  and  quality  control.  Within  these  categories 
(businesses  and  governments),  different  identity  management  systems  may  oper¬ 
ate  under  different  policies. 

In  developing  policies  for  identity  management  systems,  a  balance  needs 
to  be  struck  between  the  need  to  control  access  and  the  need  for  users  to  be  able  to 
obtain  access  as  rapidly,  transparently  and  seamlessly  as  possible.  Policies  and 
requirements  should  not  be  needlessly  complex  or  expensive  to  implement. 

Policies  also  govern  the  issuance  of  identities,  hey  establish  what  consti¬ 
tutes  a  sufficiently  unambiguous  representation  of  an  entity  for  the  intended  con¬ 
text  or  application  and  travel  with  the  identity  information  throughout  its  lifetime 
to  ensure  that  the  infonnation  is  indeed  used  only  in  accord  with  the  policy  (e.g., 
for  the  purposes  to  which  the  user  consented).  PII  requires  special  protection.  This 
may  include,  among  other  things,  that  Identity  Providers  attach  enforceable  poli¬ 
cies  to  PII,  provide  for  the  confidentiality  and  integrity  of  PII,  and  minimize  the 
amount  of  PII  used  by  applications.  Equipment  standards  need  to  reflect  these  ca¬ 
pabilities  and  requirements. 
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Annex  G  Data  Call  Instruments  and  Results 


Many  questions  were  initially  posited  by  the  Task  Force: 

1 .  How  many  government  programs  contain  Personally  Identifiable  Informa¬ 
tion  (PII)? 

2.  How  prevalent  is  the  application  of  biometric  technologies? 

3.  Do  agencies  rely  on  internally  or  externally  generated  digital  identities? 

4.  What  challenges  are  agencies  facing  with  respect  to  IdM? 

5.  What  mechanisms  exist  to  provide  insight  into  the  state  of  practice  for 
IdM  in  federal  government  programs? 

In  order  to  help  answer  these  questions,  the  Task  Force  conducted  two 
analyses: 

1 .  A  data  call  was  conducted  across  many  federal  agency  Chief  Information 
Officers  (CIOs)  in  order  to  provide  a  simple,  first-order  understanding  of 
digital  IdM  application  and  issues.  This  Annex  provides  the  results  of  this 
data  call. 

2.  A  large  number  of  Privacy  Impact  Assessments  (PIAs)  were  collected  and 
analyzed  in  order  to  quickly  and  easily  gain  insight  into  how  widespread  a 
range  of  technologies  has  been  implemented  in  government  programs. 
Most,  but  not  all,  of  the  technologies  analyzed  were  related  to  the  applica¬ 
tion  of  biometrics.  The  subsequent  Annex  provides  the  results  of  the  PIA 
assessment. 

To  ensure  that  the  Task  Force  final  report  could  be  broadly  disseminated, 
sensitive  and  classified  information  was  not  requested. 

In  order  to  obtain  a  simple,  first-order  understanding  of  digital  IdM  appli¬ 
cation  and  issues,  the  Task  Force  conducted  a  survey  of  information  systems 
across  the  Federal  Executive  Branch.  In  coordination  with  the  Office  of  Manage¬ 
ment  and  Budget  (OMB),  and  through  the  Chief  Information  Officer  (CIO)  Coun¬ 
cil,  the  28  agency  CIOs  of  the  CIO  Council  were  asked  to  provide  information  the 
following  topics: 
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1.  For  each  information  system  that  the  agency  includes  in  their  regular 
FISMA  reports,35  describe: 

a.  The  number  of  systems  that  contain  federal  information  in  identifi¬ 
able  form. 

b.  The  type  of  information  being  collected  (e.g.,  PIN/password,  date 
of  birth,  Social  Security  number  (SSN),  fingerprint). 

c.  The  number  of  systems  that  use  digital  IDs  generated  externally 
from  the  agency. 

d.  The  number  of  systems  that  request  information  from  external  par¬ 
ties  to  establish  a  digital  ID. 

e.  The  number  of  systems  that  fall  under  a  set  of  particular  sectors. 

2.  Each  agency  was  also  asked  to  provide  information  on  the  following: 

a.  List  and  describe  the  major  IdM  initiatives  within  the  agency. 

b.  List  the  agency’s  top  three  IdM  priorities. 

c.  List  the  agency’s  top  three  IdM  challenges. 

d.  List  any  agency-developed  IdM  “use  cases.” 

e.  List  and  describe  the  IdM  collaborative  efforts  your  agency  par¬ 
ticipates  in  (both  interagency  and  industry  efforts). 

f.  List  the  agency’s  biggest  in  addressing  privacy  concerns  related  to 
IdM  systems. 

g.  Discuss  whether  the  agency  has  developed  any  policies  or  proce¬ 
dures  related  to  addressing  privacy  concerns  raised  by  IdM  sys¬ 
tems. 

3.  Each  agency  was  also  asked  to  provide  information  on  the  following: 

a.  Discuss  whether  the  agency  is  funding  any  science  and  technology 
research  efforts  in  the  area  of  IdM. 

b.  Discuss  whether  the  agency  is  participating  in  any  IdM  related 
standards  activities. 

4.  Each  agency  was  also  asked  to  provide  recommendations  to  the  Task 
Force. 

Agencies  were  provided  with  a  copy  of  the  Task  Force  charter,  a  list  of 
Task  Force  participants,  instructions  for  filling  out  the  questionnaire  and  the  data 
call  questionnaire  instrument.  This  annex  provides  the  Task  Force’s  IdM  ques¬ 
tionnaire  and  the  summary  results  of  the  responses  received.  The  results  are  inter¬ 
spersed  with  the  questionnaire  that  was  distributed.  Text  that  has  a  box  around  it  is 


3  5  In  support  of  reporting  requirements  established  by  the  Federal  Information  Security  Man¬ 
agement  Act  of  2002,  the  Office  of  Management  and  Budget  (OMB)  regularly  requires  agencies  to 
report  on  several  metrics  that  relate  to  information  privacy. 
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from  the  questionnaire;  text  without  a  box  represents  high-level  summary  obser¬ 
vations.  Many  agencies  reported  data  at  the  component  or  bureau  level,  but  the 
data  has  been  “rolled  up”  and  is  presented  at  the  agency  level.  Some  text  has  also 
been  redacted  to  remove  references  to  agency  names  and  initiatives.  Raw  data 
collected  is  included  at  the  end  of  this  annex. 
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April  17,  2008 


MEMORANDUM  FOR  CIO  COUNCIL 


FROM:  Jim  Dray  (NIST),  Judith  Spencer  (GS A)  and  Duane  Blackburn  (OSTP) 

NSTC  Task  Force  on  IdM  Co-Chairs 

VIA:  Carol  Bales 

Office  of  Management  and  Budget 

SUBJECT :  NSTC  Task  Force  Inventory  of  Federal  Identity  Management  Systems 


The  National  Science  and  Technology  Council  (NSTC)  Task  Force  on  Identity  Management 
(IdM)  is  requesting  your  assistance  as  we  study  existing  IdM  activities  in  the  US  Government. 
This  interagency  Task  Force  was  established  to  assess  the  status  of  and  challenges  related  to 
IdM  technologies,  and  develop  recommendations  regarding  Federal  government’s  science  and 
technology  needs  in  this  area.  The  work  of  the  Task  Force  is  envisioned  as  a  starting  point, 
and  foundation,  for  future  government  coordination  activities  in  IdM.  A  copy  of  the  charter 
and  list  of  participants  is  attached  for  your  reference. 

One  of  the  assigned  tasks  of  the  Task  Force  is  to  establish  a  current  baseline  of  activities, 
applications,  and  challenges.  The  Task  Force  plans  to  approach  this  task  in  multiple  ways, 
one  of  which  is  to  request  assistance  from  agency  CIO  offices  to  inventory  ongoing  and 
upcoming  Federal  IdM  programs.  We  respectfully  request  your  support  by  completing  the 
attached  survey,  which  was  modeled  after  FISMA  reporting  that  you  have  recently  completed 
in  order  to  minimize  effort  on  your  part.  The  results  of  this  inventory  will  be  included  in  the 
Task  Force’s  final  report. 

For  the  purposes  of  this  Task  Force,  “identity  management”  is  defined  as  “the  combination  of 
technical  systems,  rules  and  procedures  that  define  the  ownership,  utilization,  and  safeguard 
of  personal  identity  information.  The  primary  goal  of  the  Identity  Management  process  is  to 
assign  attributes  to  a  digital  identity,  and  to  connect  that  identity  to  an  individual.” 

Please  send  an  electronic  copy  of  the  completed  survey  to  bbrykczynski@ostp.eop.gov  by 
May  9,  2008.  You  may  contact  Duane  Blackburn,  dblackburn@ostp.eop.gov,  for  general 
questions  about  the  Task  Force  and  Bill  Brykczynski,  bbrykczynski@ostp.eop.gov  for 
technical  questions  about  this  survey. 

The  Task  Force  thanks  you  in  advance  for  your  assistance. 

Attachments 

•  Instructions  for  Completing  the  Inventory  Template 

•  IdM  Inventory  Template 

•  Task  Force  Charter 

•  Task  Force  Membership 
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Instructions  for  Completing  the  Inventory 

Each  of  the  worksheets  in  the  attached  inventory  template  are  to  be  com¬ 
pleted  by  the  appropriate  agency  officials,  as  part  of  one  combined  report,  and 
transmitted  electronically  to  Bill  Brykczynski  (bbrykczynski@ostp.eop.gov)  by 
May  9,  2008.  All  parts  of  the  report  should  be  transmitted  in  the  contents  of  one 
single  e-mail.  No  additional  transmittal  letter  is  required. 

The  remaining  sections  contain  additional  definitions  and  instructions  cla¬ 
rifying  the  types  of  infonnation  being  requested  in  this  inventory. 

GENERAL  TERMS 

The  following  terms  are  used  throughout  the  document. 

Identity  -  the  unique  biological  person  defined  by  DNA;  the  physical  being 

Digital  Identity  (Digital  ID)  -  the  representation  of  Identity  in  a  digital  environ¬ 
ment. 

User  -  the  individual  whose  identity  or  digital  identity  must  be  verified.  In  e- 
government  applications  the  user  may  be  a  citizen  interacting  directly  with  the 
system.  In  law  enforcement  or  border  crossing  applications  the  “user”  may  be  a 
third  party  whose  asserted  identity  is  being  checked  against  a  watchlist  by  a  law 
enforcement  officer. 

QUESTION  1 

Question  la 

This  inventory  builds  on  data  reported  by  your  agency  in  compliance  with 
the  Federal  Information  Security  Management  Act  (FISMA).  Please  ensure  that 
the  totals  in  question  la  of  this  inventory  match  what  your  agency  most  recently 
reported  to  OMB  in  M07-19  Section  D  -  Senior  Agency  Official  for  Privacy 
(SAOP)  Question  la.  Otherwise,  please  provide  an  explanation  in  the  Comments 
section.  Answers  to  lb-le  should  be  new  data. 
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Eighteen  member  organizations  of  the  CIO  Council  representing  fifteen 
departments  or  agencies  provided  responses.  In  addition,  three  small  agencies  also 
provided  survey  responses.  Thus,  a  total  of  eighteen  departments  or  agencies  pro¬ 
vided  survey  responses.  The  responses  covered  approximately  191  agency  com¬ 
ponents  or  bureaus  and  described  a  total  of  3,400  information  technology 
programs  or  systems.  Just  over  half  of  the  programs  and  systems  in  the  response 
were  from  the  Department  of  Defense  (DOD).  Table  G-l  below  provides  a  sum¬ 
mary  of  the  number  of  systems  by  agency  represented  in  the  data  call  response. 
Note  that  the  Department  of  Energy  (DoE)  provided  a  response  to  the  data  call  but 
did  not  answer  the  system  specific  questions;  thus,  no  systems  are  reported  in  Ta¬ 
ble  G-l  from  DoE. 


Agency 

Total 

Percentage 

DHS 

111 

3.3% 

DOC 

46 

1.4% 

DOD 

1,888 

55.5% 

DoE 

0 

0.0% 

Dol 

152 

4.5% 

DOJ 

152 

4.5% 

DOS 

91 

2.7% 

EPA 

35 

1.0% 

GSA 

83 

2.4% 

HUD 

75 

2.2% 

NARA 

36 

1.1% 

NASA 

57 

1.7% 

NRC 

38 

1.1% 

RRB 

21 

0.6% 

SSA 

20 

0.6% 

SSS 

3 

0.1% 

Treasury 

404 

11.9% 

USD  A 

188 

5.5% 

Grand  Total 

3,400 

100.0% 

Table  G-l.  Summary  of  Total  Systems 
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Question  l.b:  Provide  a  count  of  the  number  of  systems  (that  are 
regularly  reported  on  in  FISMA  report  to  OMB)  for  which  the  following  in¬ 
formation  are: 

Login  Alias  —  a  string  selected  by  the  user  or  assigned  by  the  system  that 
does  not  necessarily  reflect  the  user’s  legal  name.  Common  examples  are  an  email 
address,  account  number,  or  screen  name. 

PIN/Password  —  a  string  used  in  conjunction  with  another  identifier, 
such  as  a  login  alias,  that  the  user  inputs  when  requesting  authentication. 

Legal  Name  —  a  name  associated  with  the  identity  of  a  real  person 
through  identity  proofing 

DOB  —  date  of  Birth. 

SSN  —  Social  Security  number. 

Fingerprint(s)  —  one  or  more  digitized  fingerprint  images  suitable  for 
matching  to  the  user’s  fingers. 

Iris  —  images  of  the  irises  of  one  or  both  of  the  user’s  eyes  suitable  for 
iris  recognition. 

Facial  Image  —  images  of  a  face  or  head  suitable  for  either  human  or 
electronic  facial  recognition. 

Other  Biometric  —  Iin  the  Comments  section  below  questions  1  a-f, 
please  list  any  additional  biometric  data  collected  and  used  by  the  system. 

Security  Question(s)  —  questions  such  as,  “What  is  your  mother’s  mai¬ 
den  name?”  or,  “What  is  your  favorite  color?”  to  which  the  user  must  supply  a 
pre-stored  answer. 

Token  —  hardware  or  software  token  issued  to  the  user.  Includes  RSA  Se- 
curlD  tokens  and  keys  stored  on  HSPD-12  Smart  Cards. 
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Other  (List)  —  in  the  Comments  section  below  questions  la-f,  please  list 
any  additional  identification  information  collected  and  used  by  the  system. 


The  most  common  forms  of  information  being  collected  for  IdM  are  login 
alias,  PIN/password,  legal  name,  date  of  birth  and  Social  Security  number.  Inter¬ 
estingly,  more  than  27  percent  of  the  all  systems  store  Social  Security  numbers. 

Few  systems  or  programs  collect  or  use  biometric-related  data  (e.g.,  fin¬ 
gerprints,  iris  or  facial  imaging)  or  use  security  questions  or  tokens.  See  Table  G-2 
for  a  summary  of  the  results  of  this  portion  of  the  data  call.  Note  that  many  sys¬ 
tems  collect  more  than  one  of  the  identified  information  elements  (e.g.,  a  system 
may  collect  both  a  Social  Security  number  and  a  PIN/password),  so  the  percent¬ 
ages  do  not  sum  to  100  percent. 


Type  of  Information 

Total  No. 
of  Sys¬ 
tems 

Percentage 

(N/3400) 

Login  Alias 

798 

23.5% 

PIN/Password 

1573 

46.3% 

Legal  Name 

906 

26.6% 

Date  of  Birth 

450 

13.2% 

Social  Security  Number 

930 

27.4% 

Fingerprint!  s) 

76 

2.2% 

Iris 

7 

0.2% 

Facial  Image 

59 

1.7% 

Other  Biometric  (List) 

15 

0.4% 

Security  Question(s) 

29 

0.9% 

Token 

308 

9.1% 

Other  (List) 

91 

2.7% 

Grand  Total 

5242 

Table  G-2.  Number  of  Systems  for  Which  the  Following  Information 

Is  Collected 
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Question  l.c:  Provide  a  count  of  the  number  of  systems  that  use  digi¬ 
tal  IDs  generated  externally  from  the  Agency.  Please  describe  in  Comments 
section.  An  externally  generated  digital  ID  is  a  digital  ID  (see  above)  that  is  not 
created  or  managed  by  your  agency.  In  Question  lc,  indicate  the  number  of  sys¬ 
tems  that  do  not  maintain  their  own  authentication  systems,  but,  instead,  trust  the 
digital  ID  verified  by  a  system  external  to  your  agency. 


Although  agencies  identified  28  systems  that  used  externally  generated 
digital  IDs,  only  a  few  were  mentioned  in  the  comments  section.  Those  that  were 
mentioned  included  Verisign  external  digital  certificates,  DOD  Common  Access 
Cards  (CAC),  GSA’s  Federal  E-Authentication  Federation  project,  the  Federal 
Bridge  Certificate  Authority,  a  Department  of  Treasury  application  that  generates 
certificates  and  another  agency  system  that  generates  certificates  for  an  electronic 
hearing  docket  system. 

Question  l.d:  Provide  a  count  of  the  number  of  systems  that  request 
information  from  external  parties  to  establish  a  digital  ID.  Please  describe  in 
Comments  section.  Indicate  the  number  of  systems  that  request  information  from 
identity  systems  outside  your  agency  when  establishing  a  digital  ID.  Examples 
include  verifying  legal  name-SSN  combinations  with  the  Social  Security  Admini¬ 
stration  or  retrieving  a  name  based  on  biometric  data  stored  by  the  FBI. 


Examples  of  such  systems  provided  to  the  agency  included  verifying  legal 
name-Social  Security  number  combinations  with  the  Social  Security  Administra¬ 
tion  or  retrieving  a  name  based  on  biometric  data  stored  by  the  FBI.  Agencies 
identified  28  systems  that  request  information  from  external  parties  to  establish  a 
digital  ID,  but  few  were  specifically  mentioned  in  the  comments  section. 
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NSTC  Task  Force  on  Identity  Management  Inventory  of  Federal  Systems:  Question  1 

Agency  Name: 

1.  Inventory  of  Systems  that  Contain  Federal  Information  in  Identifiable  Form 

1.  In  the  table  below,  identify  the  total  number  of  agency  information  systems  by  component/bureau.  Extend  the  worksheet  onto  subsequent  pages  if  necessary  to 
include  all  Component/Bureaus. 

For  this  inventory,  agency  systems  include  information  systems  used  or  operated  by  the  agency  or  by  a  contractor  on  behalf  of  the  Agency.  Please  ensure  that  the  totals 
in  question  la  of  this  inventory  match  what  the  agency  reported  to  OMB  in  Section  D  (SAOP)  Question  la  of  your  agency's  most  recent  Agency's  Federal  Information 
Security  Management  Act  (FISMA)  submission.  Otherwise,  please  provide  an  explanation  in  the  Comments  section. 

In  column  (a)  of  the  table  below,  identify  by  component/bureau  the  number  of  Agency  information  systems  that  contain  Federal  information  in  identifiable  form.  In 
column  (b),  identify  the  number  of  systems  in  (a)  for  which  the  listed  identifiable  information  is  collected.  Each  system  in  (a)  may  have  multiple  entries  in  column  (b).  In 
column  (c),  identify  the  number  of  systems  in  (a)  which  rely  on  externally  generated  digital  ID.  In  column  (d),  indicate  the  number  of  systems  that  provide  information  in 
response  to  requests  from  outside  the  Agency.  Descriptions  and  explanations  can  be  written  in  the  Comments  section  below  the  table. 


a. 

e: 

c. 

a! 

Number  of  systems 
that  contain 

Federal  information 

in  identifiable  form 

Number  of  systems  in  (a)  for  which  the  following  information  are 
collected 

Number  of  systems  in  (a) 
that  use  digital  IDs 
generated  externally 
from  the  Agency.  Please 
describe  in  Comments 

section. 

Numoer  ot  systems  in 

(a)  that  request 
information  from 
external  parties  to 
establish  a  digital  ID. 
Please  describe  in 

Component/Bureau 

Total  Systems 

Login  Alias 

PIN  / 
Password 

Legal  Name 

DOB 

NSS 

c 

Q. 

CD 

cn 

c 

Ll 

IE 

Facial  Image 

Other 

Biometric 

(List) 

Security 

Question(s) 

Token 

Other  (List) 

Total  Systems 

Total  Systems 

Example  Component/Bureau 

100 

80 

80 

Agency  Totals 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Comments: 
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Question  l.e:  Provide  a  count  of  the  number  of  systems  that  fall  under 
the  listed  sectors. 

The  columns  labeled  “Component/Bureau”  and  “a.”  will  be  automatically  filled 
based  on  the  data  you  provided  for  questions  la-d.  They  are  reprinted  on  this 
sheet  for  reference  purposes. 

Sectors 

Personnel  Mgmt  - 
Financial  Mgmt  - 
Acquisition  - 
Healthcare 

Entitlement  payments  - 
Tax  collection  - 
Licensing  - 
Passport/Visa  - 
Border-crossing  security  - 
Military  - 
Intelligence  - 
Cybersecurity  - 
Law  enforcement  - 
Physical  Access  - 
Logical/network  Access  - 
Retail  e-commerce  - 
Telebanking  - 
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NSTC  Task  Force  on  Identity  Management  Inventory  of  Federal  Systems:  Question  1e 

Agency  Name: 

1.  Inventory  of  Systems  that  Contain  Federal  Information  in  Identifiable  Form 
1.  In  the  table  below,  identify  the  systems  in  (a)  by  service  sector.  Choose  the  sector  that  best  fits. 


a. 

e. 

Number  of  systems 
that  contain  Federal 
information  in 

identifiable  form 

Number  of  systems  in  (a)  that  fall  under  the  following  sectors 

Government 

Operations 

Citizen  Services 

Security 

Access 

Controls 

Web-based 

Processes 

Component/Bureau 

Agency 

Systems 

Personnel 

Mgmnt 

Financial 

Mgmnt 

Acquisition  | 

Healthcare  1 

Entitlement 

payments 

Tax  collection  1 

Licensing  | 

Passport/visa  1 

Border¬ 

crossing 

security 

Military  1 

Intelligence 

Cybersecurity  1 

Law 

enforcement 

Physical  1 

Logical/networ 

k 

Retail  e- 

commerce 

Telebanking 

Example  Component/Bureau 

100 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Agency  Totals 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Comments: 


Table  G-3  rolls  up  the  count  and  percentages  of  systems  within  each  sector.  The 
majority  of  the  systems  reported  on  in  this  data  call  were  financial  management 
systems. 
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QUESTION  2 

No  additional  instructions.  See  the  inventory  template. 


NSTC  Task  Force  on  Identity  Management  Inventory  of  Federal  Systems:  Question  2 

Agency  Name: 

2.  Identity  Management  Initiatives  and  Privacy  Concerns 

2a. 

List  and  describe  the  major  identity  management  initiatives  within  your 
agency. 

2b. 

What  are  the  agency's  top  three  identity  management  priorities? 

2c. 

What  major  identity  management  challenges  does  your  agency  face? 

2d. 

Has  your  organization  developed  any  "use  cases"  with  respect  to  identity 
management?  If  so,  may  the  Task  Force  have  access  to  them?  Please 
describe,  (e.g.,  CONOPS  documents) 

2e. 

List  and  describe  the  identity  management  collaborative  efforts  your 
organization  participates  in.  Include  both  interagency  and  industry  efforts. 

2f. 

What  are  the  biggest  challenges  you  face  in  addressing  privacy 
concerns  related  to  identity  management  systems? 

2g. 

Have  you  developed  any  policies  or  procedures  related  to  addressing 
privacy  concerns  raised  by  identity  management  systems? 
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Question  2. a:  List  and  describe  the  major  IdM  initiatives  within 
your  agency. 


Seventeen  of  the  18  responding  departments  or  agencies  reported  ma¬ 
jor  initiatives  directly  related  to  HSPD-12  and  PIV  cards.  Two  departments, 
DOD  and  Treasury,  reported  major  initiatives  involving  SSN  reduction  efforts. 

Question  2.b:  What  are  the  agency’s  top  three  IdM  priorities? 


Twelve  of  the  18  responding  departments  or  agencies  reported  top 
management  priorities  directly  related  to  HSPD-12  and  PIV  cards.  Several 
agencies  also  described  single  sign-on,  centralized  agency  IdM,  encryption, 
and  two-factor  authentication  as  top  agency  priorities. 

Question  2.c:  What  major  IdM  challenges  does  your  agency  face? 


Eight  of  the  1 8  responding  departments  or  agencies  reported  top  man¬ 
agement  priorities  directly  related  to  HSPD-12  and  PIV  cards.  Seven  of  the 
responding  departments  or  agencies  reported  identity-related  priorities  associ¬ 
ated  with  interfacing  with  state,  local,  tribal,  or  foreign  partners. 

Question  2.d:  Has  your  organization  developed  any  “use  cases” 
with  respect  to  IdM?  If  so,  may  the  Task  Force  have  access  to  them? 
Please  describe,  (e.g.,  CONOPS  documents). 


Eight  respondents  representing  5  departments  or  agencies  reported  de¬ 
veloping  use  cases  or  concept  of  operations  (CONOPS)  documents.  These  use 
cases  or  CONOPS  documents  generally  are  related  to  HSPD-12  implementa¬ 
tion,  E-Authentication,  and  PKI  implementation. 

Question  2.e:  List  and  describe  the  IdM  collaborative  efforts  your 
organization  participates  in.  Include  both  interagency  and  industry  ef¬ 
forts. 
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Over  two  dozen  IdM  related  efforts  were  identified  by  respondents. 
These  efforts  include  internal-agency,  interagency,  industry,  and  standards  ac¬ 
tivities.  They  include: 

a.  DOD  Biometrics  Task  Force  (BTF) 

b.  Attribute  Based  Access  Control  Working  Group  (ABACWG) 

c.  Biometrics  Security  Consortium 

d.  Biometrics  Coordination  Group 

e.  Committee  on  National  Security  Systems 

f.  Cyber  Security  Sub  Council 

g.  DMDC  Working  groups 

h.  Defense  Enrollment  Eligibility  Reporting  System 

i.  Defense  Science  Board  Task  Force  on  Defense  Biometrics 

j .  DOD  Identity  Protection  and  Management  Senior  Coordinating  Group 
(IPMSCG) 

k.  DOD  PKI  Certificate  Policy  Management  Working  Group  (CPMWG) 

l.  E- Authentication  E-Gov  initiative 

m.  Evaluation  Program  Technical  Working  Group  (EPTWG) 

n.  Federal  Identity  Credential  Committee  (FICC) 

o.  Federal  PKI  Policy  Authority 

p.  Federated  ID  management  pilot  with  the  Directorate  of  National  Intel¬ 
ligence 

q.  FISMA  initiative 

r.  Government  Smart  Card  Interagency  Advisory  Board 

s.  GSA  E-Authentication  Technical  Working  Group 

t.  GSA  HSPD- 12  architecture  working  group  (AWG) 

u.  GSA  PKI  Working  Group 

v.  HSPD- 12 

w.  ISC  (Interagency  Security  Committee) 

x.  ISO/IEC  SC  37  (Biometrics) 

y.  ISO/IEC/JTC1/SC27  (IT  Security  Techniques) 

z.  NCITS  Ml  (Biometrics) 

aa.  NSTC  Subcommittee  on  Biometrics  and  IdM 
bb.  OASIS 

cc.  Security  Industry  Alliance  (SIA) 

dd.  SmartCard  Alliance  (SCA) 

ee.  SmartCard  IAB  (Industry  Advisory  Board) 

ff.  SSN  Tiger  Team  (a  federal  government  collaborative  effort  to  deter¬ 
mine  a  solution  for  eliminating  the  use  of  SSNs) 
gg.  Treasury  Privacy  Committee 


Question  2.f:  What  are  the  biggest  challenges  you  face  in  address¬ 
ing  privacy  concerns  related  to  IdM  systems? 
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Many  respondents  cited  funding  challenges  associated  with  addressing 
privacy  concerns.  A  few  concerns  to  highlight  include: 

•  Expanding  information  sharing  in  the  infonnation  sharing  environment 
while  simultaneously  safeguarding  personally  identifiable  information. 

•  Rapid  technology  proliferation  is  outpacing  policy  implementation. 

•  Consistent  application  of  policy  guidelines  throughout  the  enterprise. 

•  While  security  and  privacy  usually  work  well  together,  with  often 
overlapping  goals,  IdM  is  one  area  where  security  needs  and  the  rights 
to  privacy  can  come  into  conflict. 

•  Lack  of  globally  unique  identifiers. 

Question  2.g:  Have  you  developed  any  policies  or  procedures  re¬ 
lated  to  addressing  privacy  concerns  raised  by  IdM  systems? 


Of  those  departments  or  agencies  describing  privacy-related  policies  or 
procedures,  most  involved  the  requirements  (agency-specific  or  otherwise)  to 
develop  PIAs  or  System  of  Records  Notices  (SORNs).  Several  agencies  re¬ 
ported  other  privacy-related  policies  and  procedures  that  were  not  specifically 
related  to  PIAs  and  SORNs.  Eight  of  the  16  responding  departments  or  agen¬ 
cies  reported  internal  agency  policies  or  procedures  relating  to  privacy  topics. 

Question  2.h:  Is  your  agency  funding  any  science  and  technology 
research  efforts  in  the  area  of  IdM?  If  so,  please  describe. 


Only  the  DOJ  and  DOD  reported  funding  IdM  science  and  technology  re¬ 
search.  The  FBI  listed  two  efforts:  FBI  Biometrics  Center  of  Excellence  and 
the  CJIS  Next  Generation  Identification.  The  DOD  listed  the  Primary  Staff 
Assistant  for  biometrics,  and  the  Director  of  Defense  Biometrics. 

QUESTION  3 
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No  additional  instructions.  See  the  inventory  template. 


NSTC  Task  Force  on  Identity  Management  Inventory  of  Federal  Systems:  Question  3 

Agency  Name: 

3.  Research  and  Standards 


Is  your  agency  funding  any  science  and  technology  research  efforts  in  the  area  of 
identity  management?  If  so,  please  describe. 


3.b.  Is  your  agency  involved  in  any  of  the  following  Federal,  national,  international,  or  industry-related  standards  activities?  Please  only  list  those  that  are  related  to  identity  management. 


Enter  1  to  the  left  of  each  standards  organization  your  agency  has  participated  in. 

Only  include  those  that  are  related  to  identity  management. 

Point  of  Contact  (POC) 

Activity 

Title/Role 

Name 

Phone 

Email 

ITU-T  Focus  Group  on  Identity  Management 

ITU-T  Study  Group  13  (Next  Generation  Networks) 

ITU-T  Study  Group  17  (Security,  Languages  and 
Telecommunication  Security) 

ITU-T  Other  (related  to  identity  management) 

ISO/I EC/JT C 1  /SC27  (IT  Security  Techniques) 

ISO/IEC  SC  27  (Biometrics) 

ISO  Other  (related  to  identity  management) 

3rd  Generation  Partnership  Project  (3GPP) 

Alliance  for  Telecommunications  Industry  Solutions  (ATIS) 

European  Telecommunications  Standards  Institute  (ETSI) 

Initiative  for  Open  Authentication  (OATH) 

Internet  Engineering  Task  Force  (IETF) 

Liberty  Alliance  Project 

Open  Mobile  Alliance  (OMA) 

Organization  for  Economic  Cooperation  and  Development  (OECD) 

Organization  for  the  Advancement  of 

Structured  Information  Standards  (OASIS) 

World  Wide  Web  Consortium  (W3C) 

Other  (Please  list  below) 
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Question  3.a:  Is  your  agency  involved  in  any  of  the  following  fed¬ 
eral,  national,  international,  or  industry-related  standards  activities? 
Please  only  list  those  that  are  related  to  IdM.  Provide  the  position,  name, 
and  contact  information  of  any  agency  employees  who  attend  meetings  or 
contribute  to  the  deliberations  of  the  following  standards  activities  on  behalf 
of  your  agency  or  component/bureau.  At  the  end  of  the  table,  please  list  any 
additional  IdM-related  standard  setting  activities  your  agency  participates  in. 

ITU-T  —  International  Telecommunication  Union  —  Telecommunication 
Standardization  Bureau. 

ITU-T  Study  Group  13  (Next  Generation  Networks) 

ITU-T  Study  Group  17  (Security,  Languages  and  Telecommunication  Secu¬ 
rity) 

ISO  —  International  Organization  for  Standardization. 

IETF  —  Internet  Engineering  Task  Force 
W3C  —  World  Wide  Web  Consortium 

OASIS  —  Organization  for  the  Advancement  of  Structured  Information  Stan¬ 
dards 

OECD  —  Organization  for  Economic  Co-operation  and  Development 

ETSI  —  European  Telecommunications  Standards  Institute 

Liberty  Alliance  Project  —  A  business  alliance,  formed  in  September  2001 
with  the  goal  of  establishing  an  open  standard  for  federated  IdM. 

3GPP  —  3rd  Generation  Partnership  Project 

ATIS  —  Alliance  for  Telecommunications  Industry  Solutions 

OMA  —  Open  Mobile  Alliance 

OATH  —  Initiative  for  Open  Authentication 
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Table  G-4  provides  a  list  of  agencies  that  reported  having  participants 
in  14  different  standards-related  activities. 


Activity 

Participating 

Agency 

ITU-T  Study  Group  13  (Next  Generation  Networks) 

DOS 

ITU-T  Study  Group  17  (Security,  Languages  and  Telecommunication  Security) 

DOS 

ITU-T  Other  (related  to  identity  management) 

None  Identified 

ISO/IEC/JTC1/SC27  (IT  Security  Techniques) 

GSA  and  DOD 

ISO/IEC/JTC 1/SC3 7  (Biometrics) 

GSA  and  DOD 

ISO  Other  (related  to  identity  management) 

None  Identified 

3rd  Generation  Partnership  Project  (3GPP) 

None  Identified 

Alliance  for  Telecommunications  Industry  Solutions  (ATIS) 

None  Identified 

European  Telecommunications  Standards  Institute  (ETSI) 

None  Identified 

Initiative  for  Open  Authentication  (OATH) 

NASA 

Internet  Engineering  Task  Force  (IETF) 

NASA 

Liberty  Alliance  Project 

GSA  and  NASA 

Open  Mobile  Alliance  (OMA) 

None  Identified 

Organization  for  Economic  Cooperation  and  Development  (OECD) 

DOS 

Organization  for  the  Advancement  of 

Structured  Information  Standards  (OASIS) 

GSA  and  DOD 

World  Wide  Web  Consortium  (W3C) 

None  Identified 

Other  (Please  list  below) 

None  Identified 

INCITS  Ml  (Biometrics) 

DOD 

The  Open  Group 

NASA 

Overall  NIST  IdM  Activities  Contact 

DOC 

OAS  CITEL  PCC.I 

DOS 

APEC  TEL 

DOS 

Table  G-4.  Agencies  Participating  on  IdM  Standards  Activities 


Question  3.b:  Do  you  have  any  recommendations  for  the  Task 

Force? 


Several  agencies  provided  recommendations  to  the  Task  Force.  Some 
of  the  recommendations  included  the  following: 

-  Explore  the  use  of  an  alternate  identifier  vice  use  of  the  SSN. 

-  Standardize  IdM  requirements  and  fund  IdM  initiatives. 

-  Designate  OPM  as  the  authoritative  source  of  Person  Identifiers 
across  the  entire  federal  government. 
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QUESTION  4 

Use  the  box  below  question  4  to  provide  feedback  on  the  inventory  or 
provide  any  additional  information  you  think  will  help  the  Task  Force  assess 
the  status  of  and  challenges  related  to  IdM  technologies,  and  develop  recom¬ 
mendations  regarding  the  federal  government’s  science  and  technology  needs 
in  this  area. 


QUESTION  5 

No  additional  instructions.  See  the  inventory  template. 


NSTC  Task  Force  on  Identity  Management  Inventory  of  Federal  Systems:  Questions  4  and  5 
Agency  Name: 

4.  Additional  Comments  and  Recommendations 

Do  you  have  any  recommendations  for  the  Task  Force? 


5.  Identity  Management  Points  of  Contact  Information 

If  the  Task  Force  has  follow-up  questions,  please  provide  the  names  and  contact  information  for  one  to  three  identity  management 
technical  experts  within  your  agency. 


Title/Role  (e.g.,  CIO,  SAOP,  other) 

Name 

Phone 

E-mail 
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4.4.1.1.1.1.G.1  Data  Call  Results.  Question  lb:  Provide  a  Count  of  the  Number  of  Systems 


Agency 


l  a  No  of 
systems  that 
contain 
Federal  info, 
in  identifiable 
form. 


Total 

Systems 


1  b  Number  of  systems  in  (a)  for  which  the  following 
information  are  collected. 
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1c  No.  of 
systems 
that  use 
digital  IDs 
generated 
externally 
from  the 
Agency. 


Total 

Systems 


I  d  No.  of 
systems 
that  request 
info,  from 
external 
parties  to 
establish  a 
digital  ID. 


Government 

Operations 

Citizen  Services 

Security 

Access 

Controls 

Web-based 
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Total 
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1  e  Number  of  systems  in  (a)  that  fall  under  the  following  sectors 
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4.4.1.1.1.1.G.2  Data  Call  Results,  Question  2a:  List  and  Describe  the  Major  Identity  Man¬ 
agement  Initiatives  Within  Your  Agency 

1 .  DHS:  Due  to  the  increased  awareness  and  sensitivity  of  privacy  and  civil 
liberties  concerns,  the  Coast  Guard  has  implemented  several  identity  man¬ 
agement  initiatives:  1)  Handling  and  safeguarding  personally  identifiable 
information  (PII);  2)  agency-wide  system  use  of  an  alternate  identi- 
fier/Single  Sign-on  Login  (SSL);  and  3)  protection  of  personal  infonnation 
within  Information  Sharing  Environments  (ISEs). 

2.  DHS: 

a.  Follow  the  biometrics  governance  framework  through  supporting 
working  groups. 

b.  Follow  recommendations  within  the  Credentialing  Framework  Ini¬ 
tiative,  including: 

i.  Design  credentials  to  support  multiple  uses  and  environ¬ 
ments. 

ii.  Standardize  vetting. 

iii.  Establish  electronic  verification. 

iv.  Make  all  immigration  status  checks  electronic. 

v.  Promote  sharing  and  reuse  of  information,  especially  for 
enrollment  data. 

vi.  Establish  processes  for  redress  and  updating  that  do  not 
cause  undue  burden. 

c.  Manage  and  merge,  where  appropriate  credentialing  programs  such 
as  First  Responder  credentials,  HSPD  12,  TWIC,  US  PASS,  US 
VISIT,  etc. 

3.  DOC:  Compliance  with  the  requirements  of  HSPD- 12. 

4.  DOC:  HSPD- 12,  2-Factor  Authentication,  and  E-Authentication  E-Gov 
initiative  PKI. 

5.  DOD:  Develop  and  execute  DOD  Biometrics  Strategy  in  concert  with  a 
DOD  IdM  Strategy  Biometrics  strategy  based  on  the  evolution  of  Biomet¬ 
ric  enterprise  core  capabilities  for  both  friendly  and  other-than-friendly 
person. 

6.  DOD:  With  Release  2.1  A  (2  June  2008),  90-95  percent  of  the  CAMS-ME 
Production  user  population  will  utilize  PKE  for  access  to  the  Production 
Portal  application.  Post  2.1  A,  the  first  or  second  quarter  of  FY2009,  the 
remaining  CAMS-ME  Production  users,  will  use  PKE  for  access  to  the 
Production  application.  In  addition,  the  Development  and  Quality  envi¬ 
ronments  will  also  use  PKE. 

7.  DOD:  Use  of  DOD  CAC  PKI  for  IT  system  access  and  transition  to 
HSPD- 12  complaint  credentials. 

8.  DOD:  Implementation  of  the  HSPD- 12  compliant  Common  Access  Card 
(CAC),  and  Biometrics. 
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9.  DOD:  Initiatives  are  related  to  DOD  programs. 

10.  DOD:  CAC/FPIV  integration  —  meeting  the  requirements  of  HSPD-12  to 
provide  access  to  users  based  on  CAC  or  FPIV  credentials.  JEDS  —  Inte¬ 
grating  NCES’  JEDS  product  to  quickly  identify  users  and  privileges  in 
real-time. 

11.  DOD:  DOD  SSN  Reduction.  DOD  Privacy  Impact  Assessment/Privacy 
Act  (PI A/PA). 

12.  DOD:  JTF-GNO  Accelerated  PKI  Implementation,  HSPD-12  Personal 
Identity  Verification,  Smartcard/Biometrics/PKI  Interoperability.  Enter¬ 
prise  Identity  Authentication  Services,  Global  Enterprise  Attribute  Direc¬ 
tory. 

13.  DOD:  Our  organization  currently  supports  one  application  for  personnel 
management  purposes. 

14.  DoE:  HSPD-12,  E- Authentication. 

15.  DOI:  Provisioning  of  PIV  Cards  as  required  by  HSPD-12;  Implementation 
of  2-factor  authentication  for  remote  access  as  required  by  OMB  M-06-16. 

16.  DOJ:  1)  Implementation  of  HSPD-12  PIV  cards  —  Department-wide 
compliance  w/  presidential  mandate.  2)  Department-wide  enterprise  direc¬ 
tory  and  messaging  consolidation  —  Consolidation  of  infrastructure  re¬ 
quired  for  cross-component  interoperability  for  access  control  and 
electronic  messaging.  3)  Federated  ID  management  —  Piloting  ID  man¬ 
agement  brokering  technologies  to  support  heterogeneous  access  to  data 
and  systems  to  facilitate  data  sharing. 

17.  DoS:  (1)  HSPD-12  (Authentication);  (2)  IT  Consolidation  (Consolidation 
of  Department  Desktop  services  in  the  IRM  Bureau);  (3)  SMART  (auto¬ 
matically  specifies  classification  and  sensitivity  on  Department  docu¬ 
ments). 

18.  EPA:  Enterprise  IDM  implementation  includes:  Streamlining  and  integrat¬ 
ing  agency  directories,  implementing  HSPD-12  compliant  smart  cards  for 
physical  and  logical  access,  improving  user  provisioning  and  de¬ 
provisioning  and  building  capacity  for  identity  federation. 

19.  GSA:  HSPD-12  Agency  Implementation  (managed  by  HSPD-12  PMO). 
HSPD-12  PIV  card  services  (managed  by  FAS  HSPD-12  MSO).  FICC 
(managed  by  OGP).  eAuthentication  implementation  (managed  by  OCIO). 
Porta-  based  authentication,  single  sign-on  (managed  by  PBS). 

20.  HUD:  The  Major  identity  management  initiatives  at  the  Dept,  of  HUD  are 
compliance  with  HSPD-12  and  FIPS  201  Personal  Identity  Verification. 

21. NARA:  Implementing  HSPD-12,  both  for  physical  and  logical  access. 
Provide  annual  training  for  agency  employees  and  others  who  come  into 
contact  with  NARA  owned  PII  while  performing  their  official  duties  in 
accordance  with  OMB-M-07-16. 

22.  NASA:  HSPD-12  and  using  the  smartcard  to  enable  multi-factor  authenti¬ 
cation  to  physical  and  logical  assets;  E-Gov  E- Authentication. 
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23.  NRC:  IAM  project  currently  underway  includes  requirements  analysis, 
development  of  high-level  IAM  architecture,  and  strategic  plan  for  agency 
to  implement  comprehensive  IAM  infrastructure. 

24.  RRB:  Improving  the  agency’s  ability  to  meet  identity  management  initia¬ 
tives  based  upon  legislative  mandates. 

25.  SSA:  The  Social  Security  e- Authentication  Steering  Committee  was 
formed  to  provide  a  focal  point  to  oversee  e-authentication  policy,  proc¬ 
esses  and  technical  solutions. 

26.  SSS:  SSS  is  implementing  RSA  SecurlD  tokens  in  conjunction  with  nor¬ 
mal  login  management. 

27.  Treasury:  User  ID  and  Password  Login. 

28.  Treasury:  SSN  Reduction.  2  Factor  Authentication.  HSPD-12.  E- 
Authentication. 

29.  USDA:  HSPD-12,  Enterprise  Identity  Management  System,  eAuthentica- 
tion,  Non-Employee  Identity  System  (NEIS). 
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Data  Call  Results,  Question  2b:  What  are  the  Agency’s  Top  Three  Identity  Management  Pri¬ 
orities? 

1.  DHS:  1)  Handling  and  safeguarding  PII;  2)  agency-wide  system  use  of  an 
alternate  identifier/SSL;  and  3)  protection  of  personal  information  within 
ISEs. 

2.  DHS:  1)  Establish  primary  centers  of  excellence  for  all  credential- 
ing/screening/identity  services;  2)Deploy  HSPD  12  cards  and  associated 
PACS  and  LACS;  and  3)  Establish  methods  of  working  with  state,  local, 
and  other  populations  for  standardized  law  enforcement  and  disaster  re¬ 
sponse  identification. 

3.  DOC:  Compliance  with  the  requirements  of  HSPD- 12. 

4.  DOC:  1)  HSPD- 12  physical  and  logical  access;  2)  Active  Directory  Im¬ 
plementation/Consolidation;  and  3)  Expand  use  of  PKI. 

5.  DOD:  1)  Counter-terrorism;  2)  Interoperability;  and  3)  Friendly  Persons 
IdM/HSPD-12. 

6.  DOD:  No  response. 

7.  DOD:  1)  Protection  of  collected  data  while  stored  within  Agency  IT  sys¬ 
tems;  2)  Protection  of  collected  data  when  transmitted  across  Agency  en¬ 
clave  boundaries;  and  3)  Detection  when  positive  control  of  data  is  lost. 

8.  DOD:  Develop  an  AF  IdM  Initial  Capabilities  Document  (ICD),  which 
will  articulate  a  capability  gap  or  set  of  capability  gaps  identified  for  a 
specific  timeframe.  The  ICD  will  offer  potential  non-materiel  and  materiel 
solutions  and  support  the  analysis  of  alternatives  and  acquisition  process 
for  developing  and  delivering  capability  to  the  warfighter.  The  develop¬ 
ment  of  a  PKI/CAC  service-oriented  architecture,  and  the  deployment  of 
biometrics  and  CAC  capabilities  for  physical  and  logical  access. 

9.  DOD:  No  answer. 

10.  DOD:  Securing  the  PII  of  our  existing  user  populace,  ensuring  that  new 
users  are  properly  vetted  for  the  level  of  access  they  require,  and  research¬ 
ing  new  ways  to  ensure  the  integrity  of  our  collected  data. 

11.  DOD:  SSN  Reduction,  and  completion  and  submission  of  PIAs  for  sys¬ 
tems  containing  personal  identifiable  information  (PII). 

12.  DOD:  1)  JTF-GNO  Accelerated  PKI  Implementation;  2)  HSPD-12  Per¬ 
sonal  Identity  Verification  Implementation;  and  3)  Global  Enterprise  At¬ 
tribute  Directory. 

13.  DOD:  Accuracy,  speed,  ease  of  use. 

14.  DOE:  Complete  enterprise-wide  HSPD-12  implementation 

15.  DOI:  1)  HSPD-12  card  deployment;  2)  two-factor  authentication  for  re¬ 
mote  access;  and  3)  user  provisioning  systems/processes  to  integrate  phys¬ 
ical  and  logical  access  requirements. 

16.  DOJ:  1)  Data  security  —  Protection  against  loss  and/or  unauthorized  ac¬ 
cess  to  departmental  facilities,  data  and  systems;  2)  Protection  of  PII  data 
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—  Limit  uses  of  PII  data  and  ensure  data  is  protected  against  loss,  misuse 
and  unauthorized  use;  and  3)  Data  sharing  —  Support  interoperability  and 
secure  sharing  of  information  assets  for  law  enforcement,  anti-terrorism 
and  other  business  mission  imperatives. 

17.  DOS:  1)  Department’s  Public  Key  Infrastructure  (PKI)  and  biometrics 
program;  2)  IT  Consolidation  Program;  and  3)  Department’s  Employee 
Awareness  Training  Program  and  IT  Security  Professional  Subject  Matter 
Expert  Training  Program. 

18.  EPA:  1)  Implement  a  centralized  IDM  solution  for  EPA;  2)  ID  normaliza¬ 
tion,  reduction  of  redundancy  of  user  ID;  and  3)  Establish  EPA  IDM  re¬ 
quirements  and  Establish  Policies  framework. 

19.  GSA:  1)  HSPD-12  PIV  Card  issuance  to  GSA  staff;  2)  Single  signon 
agency  wide;  and  3)  Maximum  use  of  PIV  cards  for  PACS/LACS. 

20.  HUD:  1)  HSPD-12;  2)  FIPS  201;  and  3)  the  Personal  Identity  Verification 
process. 

21. NARA:  1)  Implementing  the  Federal  Identity  Card  (FIC)  by  the 
10/27/2008  deadline;  2)  Implementing  2-Factor  authentication  by 
9/30/2008;  and  3)  Evaluate  and  approve  the  GSA  Privacy  Impact  Assess¬ 
ment  for  the  USAccess  Program  powered  by  EDS  Assured  Identity.™ 

22.  NASA:  1)  Enabling  2  factor  authentication  to  PII;  2)  Encryption  of  PII  in 
transit  and  at  rest;  and  3)  Putting  all  PKI  certs  on  smartcards. 

23.  NRC:  1)  HSPD-12  2)  logical  access;  and  3)  Level  4  application  authenti¬ 
cation  assurance. 

24.  RRB:  1)  Improving  identity  management  practices  without  impacting  op¬ 
erational  efficiencies;  2)  Enhancing  agency  processes  as  it  relates  to  iden¬ 
tity  management;  and  3)  Transforming  business  tasks  by  integrating 
improved  identity  management  practices. 

25.  SSA:  1)  Single  Sign  On;  2)  Second  Factor  Authentication  Protocol;  and  3) 
Strengthening  Identity  Proofing. 

26.  SSS:  1)  Network  accounts;  2)  Regularly  changes  passwords;  and  3)  RSA 
SecurlD. 

27.  Treasury:  1)  Desktop  Security;  2)  Login  Security;  and  3)  Internet  Secu¬ 
rity. 

28.  Treasury:  1)  SSN  Reduction;  2)  HSPD-12;  and  3)  Registering,  authenti¬ 
cating  and  managing  identities  of  taxpayers  effectively.  Also,  integration 
of  Active  Directory  controls  in  all  appropriate  systems. 

29.  USDA:  1)  HSPD-12;  2)  Enterprise  Identity  Management  System;  and  3) 
Non-Employee  Identity  System. 
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Data  Call  Results,  Question  2c:  What  Major  Identity  Management  Challenges  does  Your 

Agency  Face? 

1.  DHS:  There  are  myriad  challenges  to  accomplish  the  agency’s  identity 
management  goals  requiring  significant  resources.  The  Coast  Guard  lacks 
resources  to  accomplish  many  of  the  requirements  to  ensure  alignment 
with  federal  guidelines,  e.g.,  reduction/elimination  of  SSNs,  2008  FISMA 
Reporting  Requirements,  National  Intelligence  Agency  guidance  regarding 
personal  privacy  concerns  in  ISEs,  and  the  implementation  of  the  9/11 
Commission  Act  of  2007  — Sections  803  and  804. 

2.  DHS:  Interfacing  with  state  and  local  entities  for  law  enforcement  and 
disaster  response.  Many  disparate  credentialing  programs  from  agen¬ 
cies/organizations  missions  prior  to  the  establishment  of  the  Department. 
Often  these  missions  overlap  those  of  others  within  the  Department  that 
now  have  overlapping  populations  and  distinct  technologies. 

3.  DOC:  Compliance  with  the  requirements  of  HSPD-12. 

4.  DOC:  Funding.  Lack  of  common  standards. 

5.  DOD:  1. Unfunded  requirements.  2.  Policy.  3.  Integration  and  legacy  sys¬ 
tems. 

6.  DOD:  Currently  CAMS-ME  users  supply  their  SSN  on  their  DD  Form 
2875.  This  causes  concern  re:  identity  theft.  Future  identity  management 
initiatives  should  include  the  of  other  user-specific  identification  creden¬ 
tials  to  be  used  by  security  offices,  rather  than  SSN. 

7.  DOD:  Evolving  nature  of  what  specific  data  types  apply,  the  rapid 
changes  in  the  technology  available  to  store,  process,  and  transmit  such 
data,  and  the  security  issues  of  trying  to  protect  the  data  once  gathered. 

8.  DOD:  Keeping  abreast  of  emerging  and  changing  IdM  technology,  finan¬ 
cial  restraints,  and  educating  IT  owners  and  program  managers.  Instituting 
COIs  and  data  labeling,  privilege  management,  background  vetting,  and 
IdM  and  tokens  for  non-CAC  eligible  community.  Authentication  and  au¬ 
thorization  mechanisms  as  they  deal  with  retirees,  dependents,  foreign  na¬ 
tionals  and  coalition  partners. 

9.  DOD:  No  answer. 

10.  DOD:  The  password  rules  surrounding  non-CAC  users  for  account  main¬ 
tenance  requiring  password  and  account  updates  every  60  days.  Working 
with  allied  countries  and  their  own  internal  security  rules  that  conflict  with 
DOD  security  requirements  and  procedures. 

11.  DOD:  Interfaces  with  legacy  systems.  Identifying  alternate  unique  identi¬ 
fiers  that  support  security  requirements  for  PII  and  alternate  system  archi¬ 
tectures.  Personnel  training  and  compliance  with  privacy  rules.  Protecting 
PII  in  a  system  that  is  publicly  accessible.  User  roles  and  pennissions  have 
been  implemented. 
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12.  DOD:  Intra-/Inter-Agency  HSPD-12  Logical  and  Physical  Access  Interop¬ 
erability.  Global  Enterprise  Attribute  Directory  Synchronization.  Access 
Authorization,  Privilege  Management,  Decisioning  Services. 

13.  DOD:  N/A. 

14.  DOE:  Lack  of  federal  standards;  Integration  of  diverse  legacy  contractor 
environments  to  enable  a  centralized  personnel  environment. 

15. DOI:  Disparate  systems  supporting  logical  access,  physical  access,  per¬ 
sonnel  and  contractors;  Lack  of  defined  use  cases  for  logical  access;  inte¬ 
gration  of  identity  management  functions  across  organizational  silos  (e.g., 
HR,  IT,  Physical  Security,  Law  Enforcement,  Lirst  Responders,  etc.);  Mul¬ 
tiple  federal  identity  management  initiatives  (e.g.,  HSPD-12  and  LRAC). 

16.  DOJ:  1)  Enhancement  and  alignment  of  departmental  infrastructure  and 
services  required  to  support  department-wide  usage  of  HSPD-12  PIV  II 
smartcards  for  both  physical  and  logical  access  in  addition  to  advanced 
services  such  as  digital  signing  and  encryption.  2)  State,  local,  tribal  law 
enforcement  access  to  DOJ  systems  and  data. 

17.  DOS:  Deployment  and  implementation  of  HSPD-12  world-wide  specifi¬ 
cally  at  overseas  embassies  and  consulates  is  a  continuing  challenge.  Vet¬ 
ting  foreign  nationals  and  other  federal  government  agency  staff.  Lunding 
concerns  with  ever  increasing  priority  challenges. 

18.  EPA:  Tying  all  existing  user  identity  together  including  the  PIV  card  to  a 
single  identity.  Incorporate  various  level  of  security  requirements  by  each 
system  into  a  unified  IDM  solution.  Selecting  a  COTS  solution  to  integrate 
with  EPA  current  environment.  Funding  of  the  entire  IDM  product. 

19.  GSA:  Planning  and  coordination  of  agency  investments.  Lack  of  OMB 
direction  on  eAuthentication/HSPD-12  integration  and  interoperable  cross 
agency  HSPD-12  services.  Lack  of  funding  for  identity  management  ini¬ 
tiatives. 

20.  HUD:  Obtaining  adequate  funding  to  acquire  and  thoroughly  test  new 
technologies. 

21.  NARA:  1.  Funding/resources.  2.  Complexity  of  the  challenges  for  finding 
appropriate  solutions. 

22.  NASA:  1)  Integrating  PKI  encryption  and  signing  certs  onto  the  smartcard 
while  retaining  lifecycle  management  capabilities  and  key  recovery  capa¬ 
bilities;  2.)  Identity  vetting  of  partners  in  foreign  countries;  3)  Enterprise 
mechanisms  to  metatag  data  so  that  access  can  be  limited  based  on  aspects 
of  a  digital  identity  (e.g.,  protecting  ITAR  data  from  disclosure  to  unau¬ 
thorized  foreign  nationals,  understanding  which  credential  was  used  by  the 
individual  to  obtain  access  so  assurance  level  can  be  detennined);  4)  Fed¬ 
erations  and  trust,  specifically  maturity  of  identity  federations  and  global 
mechanisms  to  enable  use  of  identity  federations,  rules,  common  controls, 
compliance  requirements  and  auditing  for  how  to  trust;  5)  Securing  ser¬ 
vices  vs.  just  authenticating  end  users. 

23.  NRC:  US  Access  (GSA)  card  incompatibility  with  NRC  Verisign  PKI. 
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24.  RRB:  Integrating  identity  management  processes  with  existing  business 
systems. 

25.  SSA:  Social  Security  is  looking  for  safe  and  secure  authentication  solu¬ 
tions  that  meet  NIST/OMB  guidance  that  the  public  will  use  and  success¬ 
fully  complete  to  access  our  Internet  and  automated  phone  transactions. 

26.  SSS:  Funding  shortages.  Changing  technical  requirements,  and  unfunded 
mandates. 

27.  Treasury:  Desktop  Security,  User  turnover,  Data  Access. 

28.  Treasury:  Single  sign-on  and  uniform  collection  of  identifiable  informa¬ 
tion.  Standing  up  an  identity  management  group.  Unfunded  mandates. 
Need  for  single  authoritative  data  source  for  employees/contractors,  regis¬ 
tering  and  authenticating  taxpayers  effectively. 

29.  USD  A:  Consolidation  of  user  identities  from  distributed  systems,  validity 
of  data  in  authoritative  systems,  lack  of  guaranteed  unique  identifiers. 
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Data  Call  Results,  Question  2d:  Has  Your  Organization  Developed  any  “Use  Cases”  with 
Respect  to  Identity  Management? 

1.  DHS:  No.  However,  the  Coast  Guard  has  implemented  the  use  of  an  Em¬ 
ployee  Identification  (einplid)  as  an  alternative  to  using  SSNs  in  many  ap¬ 
plications. 

2.  DHS:  No.  None  have  been  developed. 

3.  DOC:  No. 

4.  DOC:  Not  at  this  time. 

5.  DOD:  35  use  cases  have  been  developed  involving  joint  use  of  biometrics, 
and  as  many  as  61  total  are  under  development.  Upon  request,  a  link  can 
be  sent  to  the  product  postings. 

6.  DOD:  No  response. 

7.  DOD:  SOPs  drafted  on  when  to  report  compromise/loss  of  data.  SOPs  and 
supporting  policies  can  be  provided. 

8.  DOD:  See  attached. 

9.  DOD:  No  response. 

10.  DOD:  As  a  part  of  DTIC’s  participation  in  E-Authentication,  a  series  of 
use-cases  was  developed  with  a  focus  on  authentication  within  the  E- 
Authentication  Federation. 

11.  DOD:  No. 

12.  DOD:  1)  Army  Volunteer  PKI/IdM  CONOPS;  2)  Foreign  National 
PKI/IdM  CONOPS;  3)  Biometrics  PKI/IdM  CONOPS;  4)  RSA  SecurlD 
(OTP)  CONOPS;  5)  UID/PW  Use  CONOPS. 

13.  DOD:  N/A. 

14.  DOE:  No. 

15.  DOI:  DOI  has  not  yet  developed  any  use  cases  for  logical  access.  How¬ 
ever,  we  expect  to  do  this  as  part  of  the  effort  to  enable  two-factor  authen¬ 
tication  for  remote  access  users.  At  that  time,  we  will  be  happy  to  provide 
the  use  cases  to  the  Task  Force. 
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Data  Call  Results,  Question  2e:  List  and  Describe  the  Identity  Management  Collaborative 

Efforts  Your  Organization  Participates  In 

1.  DHS:  The  Coast  Guard  participated  in  the  SSN  Tiger  Team  and  the  Home¬ 
land  Security  Infonnation  Network  (HSIN).  The  SSN  Tiger  Team  is  a  fed¬ 
eral  government  collaborative  effort  to  detennine  a  solution  for 
eliminating  the  use  of  SSNs  and  the  legislative  requirements  to  appeal  EO 
9397  (law  signed  by  President  Roosevelt  in  1946  enacting  the  use  of 
SSNs).  Additionally,  the  Coast  Guard  was  integral  in  establishing  the  pri¬ 
vacy  framework  for  HSIN,  an  ISE  established  after  9/11  to  combat  terror¬ 
ism  nationwide. 

2.  DHS:  Smart  Card  Alliance,  NSTC  Subcommittee  on  Biometrics,  Interna¬ 
tional  Conference  on  Biometrics  and  Ethics,  Biometrics  Security  Consor¬ 
tium  (BSC),  Biometrics  Coordination  Group,  US  Army  biometrics  Task 
Force,  Interagency  Advisory  Board  (credentialing),  Defense  Science 
Board  Task  Force  on  Defense  Biometrics,  Federal  Interoperability  and 
Credentialing  Committee  (FICC). 

3.  DOC:  BEA  participates  in  the  Department’s  HSPD-12  implementation 
group. 

4.  DOC:  Federal  Identity  Credential  Committee,  E-Authentication  E-Gov 
initiative,  and  HSPD-12. 

5.  DOD:  Defense  Enrollment  Eligibility  Reporting  System. 

6.  DOD:  NSTC  Subcommittee  on  Biometrics  and  Identity  Management, 
ISO/IEC/JTC1/SC27  (IT  Security  Techniques),  ISO/IEC  SC  37  (Biomet¬ 
rics),  OASIS,  NCITS  Ml  (Biometrics). 

7.  DOD:  No  response. 

8.  DOD  N/A. 

9.  DOD:  AF  IdM  office  is  working  with  several  AF  functional  communities 
to  deploy  biometrics  and  CAC  capabilities  for  physical  and  logical  access. 
The  AF  is  also  engaged  with  the  DOD  Biometrics  Task  Force,  the  DOD 
PKI  office,  the  Defense  Manpower  Data  Center,  The  Air  Force  Personnel 
Center,  OSD/NII  and  the  National  Security  Agency. 

10.  DOD:  No  response. 

11.  DOD:  DTIC  participates  in  the  Federal  E-Authentication  program.  Work¬ 
ing  with  GSA,  DTIC  has  the  capacity  to  accept  identified  and  approved 
credentials  from  commercial  vendors  for  access  to  resources  identified  as 
being  available  to  E-Authentication  participants. 

12.  DOD:  None. 

13.  DOD:  DOD  Identity  Protection  and  Management  Senior  Coordinating 
Group  (IPMSCG),  DOD  PKI  Certificate  Policy  Management  Working 
Group  (CPMWG),  Evaluation  Program  Technical  Working  Group 
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(EPTWG),  Attribute  Based  Access  Control  Working  Group  (ABACWG), 
and  Federal  PKI  Policy  Authority  (FPKI  PA). 

14.  DOD:  ID  Management  and  Protection,  DMDC  Working  groups,  AFCEA, 
CTST. 

15.  DOE:  HSPD-12,  E-Authentication. 

16.  DOI:  Federal  Identity  Credentialing  Committee  (FICC);  GSA  PKI  Work¬ 
ing  Group;  GSA  E-Authentication  Steering  Committee;  GSA  E- 
Authentication  Technical  Working  Group 

17.  DOJ:  1)  Federated  ID  management  pilot  with  the  Directorate  of  National 
Intelligence;  2)  Participation  in  the  GSA  HSPD-12  architecture  working 
group  (AWG);  3)  Participation  in  the  Federal  Identity  Credentialing 
Committee  (FICC);  and  4)  Participation  in  the  Interagency  Advisory 
Board  (IAB). 

18.  DOS:  CNSS,  Federal  PKI  Working  Group,  FICC,  and  FPKI. 

19.  EPA:  EPA  is  not  participating  in  interagency  or  industry  efforts  at  this 
time. 

20.  GSA:  FICC  (Federal  Identity  Credentialing  Committee),  SmartCard  IAB 
(Industry  Advisory  Board),  ISC  (Interagency  Security  Committee), 
SmartCard  Alliance  (SCA),  and  Security  Industry  Alliance  (SIA). 

21.  HUD:  The  Dept,  of  HUD  participates  on  the  Federal  Identity  Credential¬ 
ing  Committee. 

22.  NARA:  As  described  in  2d,  NARA  has  the  IAA  with  the  GSA  MSO  and 
their  primary  contractor  EDS  for  identity  management.  We  have  no  agen¬ 
cy-specific  initiatives  in  this  area  from  our  personnel  security  perspective; 
we  use  OPM  to  conduct  our  background  investigations  which  helps  sup¬ 
port  the  identity  management  agreement  with  GSA. 

23.  NASA:  1)  Federal  PKI  Policy  Authority:  Karen  Petraska,  Susan  Levine;  2) 
Federal  Identity  Credentialing  Committee:  Karen  Petraska,  Will  Morrison; 
3)  Government  Smartcard  Interagency  Advisory  Board:  Tim  Baldridge. 

24.  NRC:  Attend  workshops  and  seminars  including  FICC. 

25.  RRB:  At  this  time,  the  agency  does  not  have  the  resources  to  participate  in 
interagency  and  industry  collaborative  efforts. 

26.  SSA:  Social  Security  was  an  early  partner  in  the  GSA  e-Authentication 
Federation.  As  part  of  this  federation,  Social  Security  partners  with  GSA 
and  Fidelity  Investments  to  allow  users  to  change  their  address  a  once  suc¬ 
cessfully  e-authenticated  by  Fidelity.  GSA  is  the  gateway  between  SSA 
and  Fidelity. 

27.  SSS:  FISMA  initiative  and  FISMA  auditing. 

28.  Treasury:  None. 

29.  Treasury:  HSPD-12,  Treasury  Privacy  Committee,  and  Cyber  Security 
Sub  Council. 

30.  USDA:  HSPD-12,  authentication. 
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Data  Call  Results,  Question  2f:  What  are  the  Biggest  Challenges  you  Face  in  Addressing  Pri¬ 
vacy  Concerns  Related  to  Identity  Management  Systems? 

1.  DHS:  The  Coast  Guard’s  biggest  challenge  addressing  privacy  concerns 
related  to  identity  management  systems  is  lack  of  resources  needed  for 
human  capital,  fiscal  funding,  etc.,  to  allow  the  development  of  Integrated 
Project  Teams  for  execution  of  segmented  studies  to  address  sensitive  in¬ 
formation  in  a  number  of  areas. 

2.  DHS:  Sharing  investments  and  infonnation  across  programs  without  creat¬ 
ing  a  “Master  DHS  Database.” 

3.  DOC:  Secure  storage  of  personal  information  collected  as  a  result  of  the 
implementation  of  the  requirements  of  HSPD-12. 

4.  DOC:  Funding.  Divergent  technical  standards. 

5.  DOD:  1)  Separate  myth  from  reality;  required,  legal,  perception;  2)  Ex¬ 
panding  information  sharing  in  the  information  sharing  environment  while 
simultaneously  safeguarding  personally  identifiable  information;  and  3) 
Rapid  technology  proliferation  is  outpacing  policy  implementation. 

6.  DOD:  No  response. 

7.  DOD:  There  is  no  established  audit  trail  for  tracking  data  from  its  first  col¬ 
lection  through  its  subsequent  use  during  the  course  of  its  “ownership”  by 
the  government. 

8.  DOD:  Financial  restraints,  educating  IT  owners  and  program  managers, 
and  keeping  abreast  of  emerging  and  changing  IdM  technology. 

9.  DOD:  1)  Compliance  with  privacy  laws;  2)  Staff  awareness  and  training. 

10.  DOD:  Balancing  the  requirement  to  log  and  monitor  usage  to  ensure  that 
the  user  is  using  the  site  properly  without  infringing  on  privacy. 

11.  DOD:  1)  Interfaces  with  legacy  systems;  2)  Identifying  alternate  unique 
identifiers  that  support  security  requirements  for  PII  and  alternate  system 
architectures;  3)  Personnel  training  and  compliance  with  privacy  rules;  4) 
Protecting  PII  in  a  system  that  is  publicly  accessible.  User  roles  and  per¬ 
missions  have  been  implemented. 

12.  DOD:  1)  Physical  and/or  Logical  Separation  of  Public  and  Private  Data; 

2)  Consistent  Application  of  Policy  Guidelines  throughout  the  Enterprise; 

3)  Process  Synchronization  and  Sustainment  throughout  the  Enterprise. 

13.  DOD:  A  unique  identifier  on  all  media  of  current  CAC/PIV  and  other 
agency  IDs  to  index  dbs  with. 

14.  DOE:  Cyber  security,  system  integration  (development  and  pol¬ 
icy/business  rule  integration). 

15.  DOI:  DOI  will  manage  privacy  concerns  for  identity  management  systems 
using  the  existing  processes  and  requirements  for  developing  PIAs  and 
SORNs. 
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16.  DOJ:  General  reluctance  on  the  part  of  DOJ  bureaus  to  have  any  PII 
stored  outside  of  the  agency.  Applies  to  use  in  other  agency  operated  lines 
of  business  applications  and  managed  services,  such  as  the  GSA  HSPD-12 
managed  service.  This  is  not  preventing  use  of  such  systems,  however  the 
department  addresses  these  concerns  time  and  again  with  our  components. 

17.  DOS:  DOS  already  collected  required  privacy  data  in  order  to  obtain  DoS 
identity  credentials,  the  only  new  challenge  associated  with  HSPD-12  was 
the  capturing,  storing,  and  forwarding  of  biometric  data  (fingerprints). 

18.  EPA:  Achieving  single  sign-on  across  the  enterprise. 

19.  GSA:  1)  Training  for  staff  handling  PII;  2)  Protection  of  stored  PII  data. 

20.  HUD:  The  biggest  challenges  the  Dept,  of  HUD  faces  is  the  ability  to  pro¬ 
vide  a  secure  communications  and  application  environment. 

21. NARA:  NARA’s  identity  management  system  is  in  the  developmental 
phase.  At  this  time  we  are  evaluating  the  privacy  implications  involved  in 
the  development  and  maintenance  of  our  information  management  system. 

22.  NASA:  1)  Community  misconceptions  about  what  is  on  the  smartcards, 
and;  2)  Implementing  and  enforcing  role  based  access  mechanisms. 

23.  NRC:  Assignment  of  data  responsibility. 

24.  RRB:  Maintaining  consistent  privacy  policies  with  multiple  content  re¬ 
pository  environments  and  data  sources. 

25.  SSA:  Social  Security  has  a  goal  to  offer  more  electronic  services  while 
balancing  risks  associated  with  the  improper  disclosure  of  personal  infor¬ 
mation.  The  difficulty  lies  in  detennining  how  much  risk  the  agency  is 
willing  to  take  to  make  our  electronic  services  attractive  to  the  general 
public  in  a  manner  that  adequately  protects  personal  privacy. 

26.  SSS:  Funding  shortages.  Changing  technical  requirements,  and  unfunded 
mandates. 

27.  Treasury:  User  turnover. 

28.  Treasury:  Cost,  Complexity,  Funding,  Competing  Priorities.  While  secu¬ 
rity  and  privacy  usually  work  well  together,  with  often  overlapping  goals, 
Identity  Management  is  one  area  where  security  needs  and  the  rights  to 
privacy  can  come  into  conflict. 

29.  USDA:  Lack  of  globally  unique  identifiers  and  identity  integration  in  leg¬ 
acy  applications 
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Data  Call  Results,  Question  2g:  Have  you  Developed  any  Policies  or  Procedures  Related  to 

Addressing  Privacy  Concerns  Raised  by  Identity  Management  Systems? 

1.  DHS:  Yes.  The  Coast  Guard  has  developed  policies  and  procedures  to  ad¬ 
dress  privacy  concerns  raised  by  identity  management  systems,  e.g., 
FOI/Privacy  Acts  Manual,  Safeguarding  PII,  Privacy  Incident  Response, 
Notification,  and  Reporting  Procedures  for  PII;  privacy  concerns  are  also 
addressed  in  any  Coast  Guard  directive  relating  to  Health,  Financial,  and 
Information  Security. 

2.  DHS:  Each  system  is  required  to  undergo  a  Privacy  Threat  Assessment, 
which  detennines  whether  a  PIA,  SORN,  or  other  measures  are  required. 
Systems  with  identity  data  are  secured  using  standards  based  on  FISMA. 

3.  DOC:  Yes. 

4.  DOC:  Departmental  privacy  policy  and  policy  on  2-Factor  authentication. 

5.  DOD:  1)  Privacy  Act  compliance  and  complementing  support  of  internal 
structure  and  guidance;  2)  System  of  Record  Notice;  and  3)  Updated  draft 
Privacy  Impact  Assessment. 

6.  DOD:  No  response. 

7.  DOD:  No. 

8.  DOD:  We  are  unaware  of  any  privacy  concerns  raised  by  identity  man¬ 
agement  systems  or  tools.  The  Air  Force  has  policy  and  procedures  to  pro¬ 
tect  PII  at  rest  and  in  transient.  We  also  have  policy  (Air  Force  Instruction 
(AFI)  33-332,  Privacy  Act  Program),  which  requires  system  owners  and 
developers  assess  privacy  through  the  early  stages  of  system  development. 

9.  DOD:  Modeled  on  DOD  and  other  Federal  Agency  Best  Practices. 

10.  DOD:  We  adhere  to  the  security  policies  and  requirements  as  directed  by 
the  DOD. 

11.  DOD:  No.  However,  OUSD(AT&L)  ARA  is  developing  an  SSN  Reduc¬ 
tion  and  Management  Plan. 

12.  DOD:  Anny  Regulation  (AR)  25-1,  Army  Regulation  (AR)  25-2,  DODD 
8500.1,  DODI  8500.2,  DODI  8520.2. 

13.  DOD:  No. 

14.  DOE:  No. 

15.  DOI:  DOI  has  not  developed  specific  policies  beyond  those  that  cover 
privacy  requirements  for  any  system.  System  of  Records  Notices  (SORNs) 
and  Privacy  Impact  Assessments  (PIAs)  have  been  published  as  required 
for  all  identity  management  systems. 

16.  DOJ:  Yes.  DOJ  has  developed  Privacy  Impact  Assessment  guidance  and 
templates. 

17.  DOS:  Diplomatic  Security  reports  Privacy  Impact  Assessments  (PIA) 
were  written  and  submitted  to  OMB  in  support  of  HSPD-12. 
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18.  EPA:  No  specific  privacy  concerns  have  been  identified  at  this  time. 

19.  GSA:  Yes,  GSA  Privacy  Act  Program  in  Office  of  the  Chief  Human  Capi¬ 
tal  Officer  (OCHO).  See  SORNS  for  all  GSA  IT  systems  holding  PII  data. 
Incorporated  policies  into  HSPD-12  business  process. 

20.  HUD:  HUD  has  developed  policies  and  procedures  related  to  addressing 
privacy  concerns  raised  by  identity  management  systems. 

21.  NARA:  NARA  has  issued  policies  and  procedures  necessary  to  effect  a 
sound  privacy  program.  Those  policies  will  also  apply  to  the  identity  man¬ 
agement  system.  NARA  will  develop  additional  policy  guidance  and  im¬ 
plementation  plans  as  we  learn  more  about  the  functionality  of  the  system. 

22.  NASA:  As  required  by  federal  directives. 

23.  NRC:  No. 

24.  RRB:  The  agency  has  not  yet  completed  development  of  any  policies  or 
procedures  related  to  addressing  privacy  concerns  raised  by  identity  man¬ 
agement  systems;  however,  we  would  be  interested  in  receiving  available 
information  on  the  topic. 

25.  SSA:  Yes.  Social  Security  recently  updated  its  regulations  to  address  a 
number  of  privacy  concerns,  including  those  raised  by  identity  manage¬ 
ment  solutions.  We  issued  a  specific  regulation  on  verifying  identity  elec¬ 
tronically  and  an  additional  provision  on  electronic  disclosures.  We  also 
published  a  provision  on  privacy  impact  assessments.  In  addition,  the  So¬ 
cial  Security  Information  Systems  Security  Handbook  contains  additional 
guidance  and  policies  relating  to  identity  management. 

26.  SSS:  Yes  —  HQ  orders  and  directives  to  incorporate  FIPS,  FISMA,  and 
SP800  series  recommendations. 

27.  Treasury:  No. 

28.  Treasury:  Some  bureaus  have  updated  their  policies. 

29.  USDA:  Yes.  Effort  is  focused  on  minimization  of  the  use  and  storage  of 
PII  data  first,  then  providing  appropriate  security  around  PII  that  must  be 
used  and  maintained. 


G-37 


Data  Call  Results,  Question  3a:  Is  your  Agency  Funding  any  Science  and  Technology’  Re¬ 
search  Efforts  in  the  Area  of  Identity’  Management? 

1.  DOJ:  CJIS  Biometrics  Center  of  Excellence  (FBI),  CJIS  Next  Gen  Identi¬ 
fication  (FBI). 

2.  DOD:  PSA  /  DDB. 

3.  DOD:  Pursuing  funding  to  pilot  a  BldM  project  at  Wright-Patterson  AFB, 
OH. 
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Data  Call  Results,  Question  4:  Do  you  Have  any  Recommendations  for  the  Task  Force? 

1.  DHS:  Recommend  the  Task  Force  explore  the  use  of  an  alternate  identifier 
vice  use  of  the  SSN  and  promulgate  policy  in  alignment  with  the  Office  of 
Management  and  Budget  (OMB)  guidance  to  reduce/eliminate  the  use  of 
SSN.  The  rationale  is  if  the  NSTC  Task  Force  mission  is  to  re¬ 
solve/eliminate  the  numerous  identity  management  technologies,  stan¬ 
dards  and  related  plans  that  are  being  developed  independently  at  the 
application  and  sector-specific  levels  (such  as  telecommunications,  border 
security,  financial  services,  identity  theft,  etc.),  then  the  establishment  of 
an  alternate  identifier  will  positively  contribute  to  the  technological  needs 
government- wide.  Clearly,  the  Coast  Guard  would  benefit  from  a  coordi¬ 
nated  federal  effort,  as  this  would  allow  the  agency  to  totally  transition  its 
systems  from  using  SSNs  to  the  use  of  an  alternate  identifier,  fostering 
compliance  with  OMB  guidelines,  ensuring  privacy  protection,  and  ena¬ 
bling  individuals  to  exercise  their  identities  securely.  Implementing  this 
approach  would  undoubtedly  reduce  the  overall  cost  to  the  federal  gov¬ 
ernment. 

2.  DOD:  Task  Force  review  Defense  Manpower  Data  Center  (DMDC) 
SSN/PII  Datacall  and  Analysis  Report. 

3.  DOD:  The  need  to  come  to  tenns  with  a  standard  lexicon  of  what  consti¬ 
tutes  Identity  Management  data  and  its  relationship  with  Personally  Identi¬ 
fiable  Information  if  different. 

4.  DOD:  No. 

5.  DOD:  Some  of  the  other  U.S.  departments  (e.g.,  Education,  Housing  and 
Urban  Development,  Interior,  and  Labor)  should  be  included,  as  they 
probably  have  systems  containing  federal  information  in  identifiable  form. 

6.  DOI:  DOI  fully  supports  the  need  to  develop  use  cases  for  Logical  Access 
Controls  (LACS). 

7.  EPA:  Any  materials  produced  by  the  Task  Force  should  reflect  the  follow¬ 
ing  operating  principles:  1)  Access  to  PII  should  be  role-based  and  limited 
to  the  minimum  amount  needed  to  perform  whatever  the  necessary  func¬ 
tion;  and  2)  Any  PII  that  is  transmitted  from  one  point  to  another  should 
have  proper  safeguards  in  place  to  protect  the  information. 

8.  GSA:  Please  improve  description  of  breakdown  for  Question  le.  You 
should  provide  a  clearer  explanation  of  what  each  category  includes,  and 
also  add  an  “Other”  column  just  for  checking  total  match  column  la. 

9.  SSA:  To  meet  the  challenges  of  delivering  high  quality  services  to  citi¬ 
zens,  the  SSA  is  aggressively  pursuing  a  range  of  electronic  service  deliv¬ 
ery  methods  as  part  of  our  strategic  planning.  These  methods  require 
strong  identity  management  capabilities  to  ensure  the  public  confidence. 
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SSA  recommends  that  the  NSTC  Task  Force  consider  IdM  activity  from  a 
broad  perspective  that  includes  citizen  oriented  services  as  well  as  counter 
terrorism.  The  Task  Force  should  proceed  as  expeditiously  as  possible  in 
order  to  provide  agencies  with  standards,  guidance,  etc.  that  may  be  inte¬ 
grated  into  agencies’  planning  and  architectures. 

10.  Treasury:  Standardize  identity  management  requirements  and  fund  iden¬ 
tity  management  initiatives. 

11.  USDA:  Designate  OPM  as  the  authoritative  source  of  Person  Identifiers 
across  the  entire  federal  government. 

12.  DOD:  Identity  Management  is  a  process  that  overarches  numerous  organi¬ 
zations  and  equities  involved  in  technology  and  end-user  processes.  There 
is  a  need  for  an  enduring  governance  structure  to  routinely  facilitate  cross- 
organizational  collaboration  in  this  area,  both  at  the  federal  government  — 
wide/interagency  level,  and  in  major  federal  organizations  with  complex 
IdM-related  missions,  such  as  the  Department  of  Defense.  Important  to 
coordinate  efforts  across  the  federal  government  for  best  results  and  cost 
effectiveness. 
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Annex  H  Additional  Information  from  PIA  Assessment 


This  annex  provides  the  results  of  the  PIA  assessment  conducted  by 
the  Task  Force.  A  PIA  is  an  E-Government  Act-mandated  analysis  of  how  PII 
is  handled  by  electronic  systems  of  the  federal  government.  A  PIA  has  three 
goals: 

1.  To  ensure  handling  of  PII  conforms  to  privacy  protection  require¬ 
ments. 

2.  To  detennine  the  risks  and  effects  of  collecting,  maintaining  and  dis¬ 
seminating  PII  through  an  electronic  system. 

3.  To  evaluate  protections  and  alternatives  for  handling  PII  to  limit  poten¬ 
tial  privacy  risks. 

The  PIA  process  allows  systems  designers  and  programs  sponsors  to 
approach  privacy  systemically,  in  the  design  stage,  by  thinking  through,  and 
laying  out,  the  ways  in  which  sensitive  infonnation  is  to  be  collected,  used 
and  stored  within  government  systems.  This  process  adds  to  the  desired  tone 
in  government’s  management  of  privacy  by  allowing  for  transparency  in  this 
analysis,  through  the  generation  and  publication  of  PIAs  for  each  such  pro¬ 
gram. 


The  Task  Force’s  effort  to  collect  and  analyze  all  publicly  available 
federal  government-created  PIAs  had  several  aims.  The  first  of  these  was  to 
systematically  investigate  the  types  of  data  collected  by  electronic  systems 
across  the  government.  Additionally,  the  Task  Force  sought  to  identify  simi¬ 
larities  and  differences  across  PIAs  toward  better  understanding  the  policies 
and  privacy  protections  implemented  by  the  various  U.S.  agencies  generating 
PIAs.  Ultimately,  this  collection  and  analysis  effort  hopes  to  use  PIAs  to  iden¬ 
tify  and  understand  existing  efforts  in  IdM  across  the  federal  government. 

For  this  effort,  PIAs  were  used  as  the  points  of  analysis  for  several  rea¬ 
sons.  First,  because  their  creation  and  dissemination  is  mandated  by  the  E- 
Govemment  Act  of  2002,  a  majority  of  created  PIAs  are  readily  available 
from  government  Web  sites.  Additionally,  because  PIAs  follow  a  standardized 
format  for  dissemination,  they  are  easily  comparable  to  each  other.  For  the 
purposes  of  this  analysis,  only  publicly  available  PIAs  were  collected  and  ana- 
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lyzed;  PIAs  for  sensitive  or  classified  systems  were  not  requested  nor  in¬ 
cluded. 


The  Task  Force  collected  1,595  PIAs,  largely  from  agency  Web  sites, 
in  order  to  detennine  what  IdM-related  infonnation  could  be  obtained.  In  or¬ 
der  to  help  constrain  the  collection  effort,  we  focused  on  obtaining  PIAs  from 
only  the  agencies  represented  on  the  Task  Force.  The  list  of  agency  PIAs  ini¬ 
tially  collected  from  agency  Web  sites  was  provided  to  the  representatives  of 
each  agency  on  the  Task  Force,  in  order  to  confirm  that  our  collection  of  PIAs 
was  accurate  and  complete.  Confirmation  was  received  from  the  majority  of 
agencies  queried. 

These  PIAs  were  then  converted  to  PDF  format  (when  required)  and 
compiled  them  into  a  searchable  catalog  using  Adobe  Acrobat.  For  each  PIA, 
we  also  captured  the  bureau  (e.g.,  U.S.  Mint  and  IRS  for  the  Treasury  De¬ 
partment)  and  documented  this  infonnation  in  an  Excel  spreadsheet  for  easy 
reference. 

However,  it  must  be  noted  that  though  our  collection  of  PIA  docu¬ 
ments  was  nearly  comprehensive  and,  thus,  the  following  keyword  analyses  of 
the  collected  PIAs  should  be  considered  complete,  there  does  exist  additional 
PIA  documents  that  were  excluded  from  the  IdM  Task  Force  review  due  to 
their  being  sensitive  (e.g.,  For  Official  Use  Only)  or  classified.  As  a  result, 
overall  conclusions  about  the  use  of  these  terms  in  the  PIA  documents  col¬ 
lected  cannot  be  considered  without  the  caveat  that  for  many  of  these  terms 
there  may  exist  additional  U.S.  Government  programs,  departments,  or  sys¬ 
tems  that  do  likely  collect  data  on  or  use  the  terms  below,  thereby  rendering 
any  conclusion  we  might  draw  from  this  PIA  analysis  about  the  usage  of  these 
terms  and  the  data  collections  they  entail  across  the  federal  government 
somewhat  incomplete. 

The  Task  Force  identified  thirteen  terms  to  be  used  for  analysis  of  the 
PIA  database:  biometric(s),  DNA,  fingerprint(s),  facial,  identity,  iris,  personal 
identification  number  (PIN),  discretionary  access  control,  mandatory  access 
control,  role-based  access  control,  token,  two-factor  authentication,  and  voice. 
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The  list  of  terms  is  skewed  toward  those  that  are  related  to  biometrics,  in  part 
because  the  field  of  biometrics  is  a  rich  source  of  terminology  that  is  identity- 
specific. 

Table  H-l  summarizes  the  results  of  the  keyword  analysis.  Of  the  13 
tenns  that  were  analyzed  across  1,595  PIA  documents,  Table  H-l  also  lists  the 
total  number  of  instances  (i.e.,  “hits”)  of  the  tenn  across  all  PIA  documents, 
the  total  number  of  PIA  documents  that  include  the  term  at  least  once,  the 
number  of  false  positive  instances  (e.g.,  a  search  on  the  term  “iris”  resulted  in 
one  of  the  72  hits  being  a  reference  to  a  database  management  system  with  an 
acronym  of  “IRIS”),  and  some  summary  observations. 


H-3 


Term 

Instances 

#  of 

Documents 

False 

Positives 

Summary  Observations 

Biometric(s) 

1174 

131 

32 

99  PIAs  use  the  term  biometric;  Half  relate 
to  Personal  Identity  Verification  (PIV)  card; 
Half  are  DHS  and  DOJ  systems. 

DNA 

82 

27 

15 

12  PIAs  use  the  term  DNA;  Many  are  DoS 
systems. 

Fingerprint(s) 

437 

81 

12 

69  PIAs  use  the  term  fingerprints;  Most 
associated  with  PIV  cards. 

Facial 

54 

12 

0 

12  PIAs  use  the  term  facial;  Four  use  the 
term  in  relation  to  facial  images  collected 
for  PIV  cards;  Eight  refer  to  the  collection 
of  facial  images  for  identification,  security, 
or  immigration  systems. 

Identity 

1087 

218 

18 

200  PIAs  use  the  term  identity;  Most  relate 
to  allowing  a  user  access  to  a  particular  sys¬ 
tem  or  database. 

Iris 

72 

15 

7 

8  PIAs  discuss  the  use  of  iris  scans;  Most 
are  TSA  programs. 

Personal  Identifica¬ 
tion  Number  (PIN) 

58 

43 

0 

43  PIAs  use  the  term  PIN;  Mostly  used  for 
access  control. 

Discretionary  Ac¬ 
cess  Control  (DAC) 

15 

9 

2 

7  uses  of  the  term  DAC;  All  are  general  in 
nature,  not  specific. 

Mandatory  Access 
Control  (MAC) 

11 

5 

0 

5  uses  of  the  term  MAC;  Most  are  DHS 
systems. 

Role-based  Access 
Control  (RBAC) 

122 

59 

0 

59  PIAs  use  the  term  RBAC;  Most  describe 
database  protection  controls. 

Token 

23 

15 

0 

15  PIAs  use  the  term  token;  Half  refer  to 
RSA  SecurlD  tokens. 

Two-factor 

Authentication 

23 

10 

0 

10  PIAs  discuss  two-factor  authentication; 
Most  associated  with  PIV  cards. 

Voice 

59 

24 

18 

6  PIAs  use  the  term  voice  for  authentica¬ 
tion;  Most  use  the  term  “voice  print”  for 
biometric  purposes 

Table  H-l.  Summary  of  Keyword  Results 


The  principal  observation  of  this  analysis  was  that  few  PIAs  include 
the  use  of  terms  that  relate  to  biometrics  (e.g.,  iris,  voice,  facial,  DNA).  We 
conclude  that  few  of  the  programs  that  are  required  to  produce  PIAs  are  using 
biometric  technology.  The  Task  Force  notes  that  while  the  PIA  analysis  is  very 
helpful  for  its  intended  purpose,  augmenting  the  PIAs  with  specific  identity- 
related  questions  would  provide  much  more  insight  into  the  current  state  of 
practice  in  how  identity  is  managed  and  implemented  within  the  Executive 
Branch. 
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A  Privacy  Impact  Assessment  (PIA)  is,  according  to  the  Office  of 
Management  and  Budget’s  Guidance  for  Implementing  the  Privacy  Proce¬ 
dures  of  the  E-Govemment  Act  of  2002: 

...An  analysis  of  how  (personally  identifiable)  infonnation  is  han¬ 
dled:  (i)  to  ensure  handling  confonns  to  applicable  legal,  regula¬ 
tory,  and  policy  requirements  regarding  privacy,  (ii)  to  determine 
the  risks  and  effects  of  collecting,  maintaining  and  disseminating 
information  in  identifiable  form  in  an  electronic  infonnation  sys¬ 
tem,  and  (iii)  to  examine  and  evaluate  protections  and  alternative 
processes  for  handling  information  to  mitigate  potential  privacy 
risks.36 

The  E-Government  Act  of  2002  requires  that  any  federal  government 
agency  wishing  to  develop  an  electronic  system  to  “collect,  maintain,  or  dis- 

TO 

seminate”  personally  identifiable  information  (PII)  about  an  individual  must 
conduct  a  PIA.  In  sum,  the  government  requires  the  creation  of  PIAs  when  a 


36  M-03-22.  OMB  Guidance  for  Implementing  the  Privacy  Provisions  of  the  E-Government 

Act  of  2002.  Web  site,  available  from: 
http://www.whitehouse.gOv/omb/memoranda/m03-22.html#2 

37  A  summary  of  the  E-Government  Act  of  2002  can  be  found  at  this  Web  site: 

http://www.whitehouse.gov/omb/egov/g-4-act.html,  as  can  a  link  to  the  full-text  of  the 
Act. 

38  Personally  identifiable  information  is  defined  by  OMB  M-03-22  as  “information  in  an  IT 

system  or  online  collection:  (i)  that  directly  identifies  an  individual  (e.g.  name,  address, 
social  security  number  or  other  identifying  number  or  code,  telephone  number,  email  ad¬ 
dress,  etc.)  or  (ii)  by  which  an  agency  intends  to  identify  specific  individuals  in  conjunc¬ 
tion  with  other  data  elements,  i.e.,  indirect  identification.  (These  data  elements  may 
include  a  combination  of  gender,  race,  birth  date,  geographic  indicator,  and  other  descrip¬ 
tors).” 

The  2002  E-Gov  Act  as  “any  representation  of  information  that  permits  the  identity  of  an  in¬ 
dividual  to  whom  the  information  applies  to  be  reasonably  inferred  by  either  direct  or  in¬ 
direct  means.”  Information  “permitting  the  physical  or  online  contacting  of  a  specific 
individual”  (see  section  208(b)(  1  )(A)(ii)(II))  is  the  same  as  “information  in  identifiable 
form.” 
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system  will  use  PII  and  through  the  PIA,  the  government  aims  to  mitigate  any 
privacy  risk  before  the  system  is  deployed. 

KEYWORD  ANALYSIS 

Iris 

A  search  for  “iris”  returned  15  PIA  documents  containing  the  term 
“iris.”  Of  those  15  documents,  seven  were  false  positives  (e.g.,  references  to 
database  systems  such  as  IRIS  and  IRISV3),  revenue  control  systems  (i.e.,  the 
Alcohol  and  Tobacco  Tax  and  Trade  Bureau’s  Integrated  Revenue  Infonnation 
System)  or  HHS  time  management  systems).  The  remaining  eight  documents 
referencing  the  term  “iris”  do  so  in  regard  to  the  collection  of  biometric  data 
from  a  scan  of  a  human  iris. 

Of  the  eight  PIAs  making  at  least  one  reference  to  biometric-related 
“iris,”  all  but  one  are  for  Transportation  Security  Administration  (TSA)  pro¬ 
grams;  the  last  is  for  Federal  Bureau  of  Investigation  (FBI)/DHS  data  sharing 
module  that  has  the  potential  to  collect  biometric  data,  including  iris  scans. 

Iris  is  discussed  as  one  element  of  biometric  data,  usually  alongside 
fingerprint  data.  Iris  scans  are  considered  voluntary  biometric  data  for  the 
TSA  PIAs  -  secondary  biometric  data  used  for  evaluative  purposes,  (or  in  the 
case  of  the  Registered  Traveler  Pilot,  for  research  purposes  to  develop  a  bio¬ 
metric  iris  standard  with  National  Institute  of  Standards  and  Technology 
(NIST)). 

From  this  analysis  we  conclude  that  few  publicly  visible  programs 
within  the  U.S.  government  collect  or  seek  to  collect  iris  scans  as  biometric 
data  in  any  capacity,  and  those  that  do  currently  intend  to  use  it  in  a  secondary 
capacity  only.  With  that  in  mind,  we  also  note  that  our  PIA  analysis  indicates 
that  iris  scans  are  currently  limited  to  the  TSA,  and  mostly  to  the  Registered 
Traveler  Program  in  an  entirely  voluntary  and  non-limiting  capacity. 

Fingerprint 
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A  search  for  “fingerprint,”  which  also  returned  results  for  “finger¬ 
prints,”  revealed  8 1  PIA  documents  mentioning  the  tenn  “fingerprint”  or  “fin¬ 
gerprints.”  A  closer  analysis  unearthed  twelve  incorrect  match  results  —  all 
from  the  Department  of  Justice/FBI  —  which  occur  due  to  the  way  the  PIAs 
were  captured  (in  capturing  PIA  documents  from  HTML,  we  inadvertently 
and  unavoidably  also  captured  extraneous  text,  which  in  this  case  included  a 
link  to  “fingerprint”  not  relevant  to  the  PIAs). 

After  discounting  the  incorrect  matches,  a  total  of  69  PIAs  referencing 
the  tenn  fingerprint  were  collected  for  10  departments.  We  roughly  catego¬ 
rized  the  PIAs  into  3  categories: 

•  PIAs  referencing  fingerprint  collection  activities  to  be  used  exclusively 
for  internal  Human  Resources  (HR)  or  Personal  Identity  Verification 
(PIV)  card  systems 

•  PIAs  for  systems  that  require  the  collection  of  fingerprints  as  a  form  of 
biometric  data 

•  PIAs  for  systems  that  contain  and  pass  along  fingerprint  and  other 
biometric  data  but  do  not  seek  to  collect  it 

For  5  of  the  10  departments  with  PIAs  referencing  “fingerprint,”  the 
PIAs  could  be  categorized  into  PIAs  using  fingerprints  for  HR  or  PIV  card 
systems  (15  PIAs  in  5  departments).  For  the  other  five  departments,  the  major¬ 
ity  of  PIAs  referencing  fingerprints  in  a  biometric  data  collection  capacity 
were  found  in  DHS  (34  of  40  PIAs  are  for  DHS  programs).  PIAs  for  systems 
containing  and  transmitting  fingerprint  data  were  more  evenly  distributed 
across  DHS,  DOD,  DOJ/FBI,  and  DOS. 

A  search  for  “fingerprints”  found  67  documents  with  439  instances  of 
the  tenn  used.  52  of  those  67  documents  also  contain  the  term  “fingerprint,” 
the  other  15  represent  PIAs  that  were  not  captured  in  the  above  search  for 
“fingerprint.”  Cross-referencing  PIAs  that  describe  the  collection  or  transmis¬ 
sion  of  “fingerprint”  or  “fingerprints”  indicate  that,  after  disallowing  for  false 
positives,  83  PIAs  captured  by  our  collection  efforts  use  the  term  “fingerprint” 
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or  “fingerprints.”  Of  these  83  PIAs,  all  but  one  refer  to  fingerprints  in  the  most 
well-known  sense  of  the  word;  that  is,  the  imprint  of  fingertips  captured  on 
paper  or  digital  image.  The  outlying  PI  A  —  for  the  Centers  for  Disease  Con¬ 
trol  and  Prevention  (CDC)  PulseNet  program  —  discusses  the  collection  of 
“DNA  fingerprints”  —  unique  DNA  profiles  used  in  a  manner  similar  to  typi¬ 
cal  fingerprints.  Overall,  we  found  that  a  limited  number  of  PI  A  documents 
across  the  federal  government  mention  the  terms  “fingerprint”  or  “finger¬ 
prints.”  Those  that  do  mention  either  term  do  so  primarily  in  reference  to  the 
capture  and  dissemination  of  biometric  data,  with  the  remainder  mentioning 
the  terms  in  relation  to  the  use  of  fingerprint  data  in  meeting  Homeland  Secu¬ 
rity  Presidential  Direction  12  (HSPD-12)  requirements  for  PIV  cards. 

Two  Factor  Authentication 

A  search  for  “two  factor  authentication,”  which  also  returned  the  vari¬ 
ant  “two-factor  authentication,”  returned  10  PIA  documents  referencing  the 
tenn.  The  10  PIAs  mentioning  two-factor  authentication  originate  in  multiple 
departments,  including  DOC  (National  Oceanic  and  Atmospheric  Administra¬ 
tion  (NOAA)),  DHS,  DOD  (Air  Force),  DOJ,  GSA,  HHS  (National  Institute 
of  Health  (NIH)),  National  Science  Foundation  (NSF),  and  Department  of  the 
Treasury. 

Several  of  the  PIAs  using  the  term  two-factor  authentication  do  not  of¬ 
fer  an  explicit  definition  for  the  term,  or  specify  which  “factors”  are  required 
for  authentication.  About  half  of  the  PIA  documents  discuss  two-factor  au¬ 
thentication  as  part  of  a  strategy  to  limit  access  to  personal  information  stored 
in  government  computer  systems;  the  remaining  half  describe  two-factor  iden¬ 
tification  in  the  context  of  PIV/Common  Access  Card  (CAC)/Transportation 
Worker  Identification  Credential  (TWIC)  cards  and  the  PII  collected  to  sup¬ 
port  the  security  of  those  cards. 

Five  of  the  10  PIAs  discussing  two-factor  authentication  mention  a 
HSPD-12-based  identity  card  as  one  of  the  two  factors  required  for  authenti¬ 
cation.  Other  factors  mentioned  by  the  PIAs  include  biometric  data,  a  PIN,  an 
RSA  token,  and  a  password. 
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Biometric  (includes  biometrics) 


A  search  for  “biometric,”  which  also  returned  results  for  “biometrics,” 
returned  131  PIA  documents  mentioning  the  term(s)  “biometric(s).”  Over  half 
of  the  PIAs  collected  mentioning  the  terms  biometric  or  biometrics  (or  both) 
are  for  DHS  databases  or  systems.  The  remainder  is  from  DOJ,  GSA,  HHS, 
NASA,  DOS,  and  the  VA.  Most  (20)  of  the  VA  PIAs  (22  total)  mentioning 
biometrics  should  be  recorded  as  false  positives,  since  they  include  the  text 
biometric  but  it  is  not  referenced  to  the  actual  content  of  the  PIA;  similarly, 
twelve  of  the  1 5  DOJ  PIAs  discussing  biometrics  do  so  without  any  reference 
to  the  actual  content  of  the  PIA  and  should  be  considered  False  Positives. 

To  generalize  briefly,  PIAs  from  departments  other  than  DHS  and  DOJ 
use  the  term  biometric  generally  in  reference  to  data  collected  for  compliance 
with  HSPD-12  rather  than  for  security/immigration/criminal  investigation 
purposes,  whereas  DHS  and  DOJ  PIAs  referencing  biometrics  do  so  for  non- 
PIV  card  purposes. 

Drilling  further  into  the  use  of  the  terms  “biometric”  and  “biometrics” 
in  DHS  PIAs,  we  find  that  in  some  PIAs  the  term  biometric  is  well-defined, 
referencing  the  various  types  of  biometric  data  collected  (e.g.,  fingerprints, 
voice  prints,  iris  scans),  while  in  others  these  data  are  not  described.  The  DHS 
PIAs  collected  describe  several  different  uses  of  biometric  data  between  and 
within  DHS  databases  and  systems.  For  example,  in  some  DHS  PIAs,  biomet¬ 
ric  data  is  used  as  an  access  control  data  point;  that  is,  iris  scans  are  used  for 
physical  access  controls  and  are  stored  in  a  database. 

Identity 

A  search  for  “identity”  returned  218  PIA  documents  mentioning  the 
tenn  “identity.”  Those  PIAs  referencing  the  tenn  “identity”  were  created  by 
multiple  departments,  including:  DOC,  DHS,  DOJ,  FTC,  GSA,  HHS,  NASA, 
NSF,  SSA,  State,  DOT,  Treasury,  and  the  VA.  The  VA  again  features  multiple 
PIAs  that  register  a  false  positive  for  the  actual  use  of  the  term  “identity”  — 
as  for  the  term  “biometric”  above,  these  PIAs  registering  false  positives  in- 
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elude  the  term  we  searched  for  as  part  of  a  generic  section  header,  but  did  not 
actually  report  use  of  the  term  for  the  actual  system  for  which  the  PIA  was 
created  for  —  leaving  approximately  200  PIAs  with  valid  references  to  the 
tenn  identity. 

Generally,  PIAs  described  three  types  of  systems/databases  from 
which  the  use  of  the  term  identity  within  the  PIAs  collected  stems:  to  verify 
identities,  to  authenticate  identities,  and  to  communicate  an  identity  or  ele¬ 
ments  of  an  identity.  On  the  broadest  level,  the  majority  of  PIAs  focus  on  the 
authentication  of  identities  in  relation  to  allowing  a  user  access  to  a  particular 
system  or  database.  Generally,  only  DHS,  State,  and  DOJ/FBI  PIAs  discuss 
the  verification  of  identity  in  a  criminal/national  security  sense,  or  discuss  the 
transmission  of  identity  elements  across  systems. 

Facial 

A  search  for  “facial”  returned  12  PIA  documents  mentioning  the  term. 
Of  the  12  PIAs  collected,  four  departments  are  represented  (DHS,  DOJ,  HHS, 
and  the  VA).  Four  of  the  12  PIAs  reference  the  tenn  in  relation  to  facial  im¬ 
ages  collected  for  PIV  cards  systems  in  accordance  with  HSPD-12;  the  other 
eight  PIAs  refer  to  the  collection  of  facial  images  for  identification,  security, 
or  immigration  systems. 

Interestingly,  facial  images  are  not  referred  to  as  biometric  data  by  any 
of  the  PIAs,  but  rather  as  biographical  data  by  several.  For  several  of  the  DHS 
databases  collecting  facial  images  for  security/identification  purposes,  facial 
images  are  treated  as  PII  and  are  governed  by  specific  privacy  protections. 

Personal  Identification  Number  (includes  PIN) 

A  search  for  the  tenn  “personal  identification  number,”  which  over¬ 
lapped  with  a  search  for  the  term  “PIN,”  returned  43  PIA  documents  mention¬ 
ing  one  or  both  of  the  terms.  The  43  PIAs  collected  for  systems  discussing  the 
tenn  personal  identification  number  come  from  several  federal  government 
departments  including  DOC,  DHS,  DOD,  DOJ,  GSA,  SSA,  and  Department 
of  the  Treasury  (mostly  the  Internal  Revenue  Service  (IRS)). 
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The  SSA  uses  PINs  as  a  form  of  access  control  to  administration  data¬ 
bases  containing  PII  of  either  employees  or  citizens,  requiring  that  employees 
accessing  SSA  databases  to  possess  and  apply  a  PIN  for  access. 

For  PIAs  for  systems  and  databases  of  the  IRS,  PINs  are  not  used  as  a 
form  of  access  control,  but  treated  usually  as  a  unique  identifier,  or  an  element 
of  an  electronic  identity,  and  are  thus  included  in  PIAs  because  they  are  con¬ 
sidered  to  be  PII. 

For  PIAs  from  non-SSA  and  non-IRS  systems,  PINs  are  used  for  au¬ 
thentication  purposes,  usually  as  part  of  a  PIV  card,  and  are  considered  more 
as  biographical  data  and  less  as  biometric  data.  Overall,  we  found  that  a  lim¬ 
ited  number  of  PIA  documents  across  the  federal  government  mention  the  use 
of  personal  identification  numbers  (PINs).  The  majority  of  PIAs  referencing 
PINs  do  so  as  a  form  of  access  control  rather  than  as  a  form  of  biographical 
data,  and  given  the  number  of  PIA  documents  collected  mentioning  some  type 
of  access  control  system,  we  anticipate  that  personal  identification  numbers 
will  continue  to  be  implemented  in  this  capacity  into  the  future. 

Token 

A  search  for  “token”  returned  1 5  PIA  documents  mentioning  the  term 
“token.”  The  15  PIAs  collected  that  mention  the  term  Token  are  from  systems 
in  five  departments:  DHS,  DOJ,  HHS,  Department  of  the  Treasury,  and  the 
VA.  The  PIAs  reference  two  “types”  of  tokens;  in  one  sense,  tokens  refer  to  a 
small  physical  media  item  embedded  with  a  chip  that  provides  a  set  piece  of 
information  necessary  to  authenticate  the  access  of  the  item’s  carrier  to  a  sys¬ 
tem;  in  the  other  sense,  tokens  refer  to  a  unique  piece  of  identifying  informa¬ 
tion  —  but  not  a  physical  item  —  that  allows  a  user  access  to  a  secured 
system.  Several  of  the  DHS  PIAs  refer  to  this  latter  use  of  tokens  in  describing 
a  form  of  access  control  as  including  “two  token  authentication.” 

Of  the  PIAs  that  refer  to  tokens  as  a  physical  item  displaying  a  unique 
identifier,  about  half  reference  the  popular  RSA  SecurlD  tokens;  the  remain¬ 
der  only  refer  to  “access  control”  tokens  or  simply  “secure  tokens.” 
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Voice 


A  search  for  the  term  “voice”  returned  24  PIA  documents  mentioning 
the  term  in  some  capacity.  However,  we  were  only  interested  in  the  use  of  the 
tenn  “voice”  in  an  authentication  or  verification  capacity  —  we  were  not  in¬ 
terested  in  PIAs  for  voicemail  and  automated  voice  systems.  We  found  that 
the  majority  of  the  24  PIAs  collected  that  reference  the  term  voice  do  so  in 
reference  to  automated  telephone  systems  used  to  provide  information  to  users 
or  to  voice-mail  systems  —  only  six  of  the  24  PIAs  collected  referenced  the 
tenn  voice  with  regard  to  authentication  or  verification  purposes.  We  collected 
PIAs  which  included  the  term  voice  from  seven  federal  government  depart¬ 
ments,  including:  DOC,  DHS,  DOJ,  HHS,  DOS,  Department  of  the  Treasury 
(IRS  only),  and  the  VA.  However,  only  DHS,  DOJ,  and  DOS  featured  PIAs 
regarding  systems  in  security/crime/defense-sectors;  it  is  those  PIAs  that  ref¬ 
erenced  the  term  voice  with  regard  to  identity/privacy-related  issues. 

For  those  six  PIAs  referencing  the  term  voice  as  used  for  authentica¬ 
tion  purposes,  two  were  from  DHS,  two  from  DOJ  (both  FBI),  and  two  from 
DOS.  Each  of  these  PIAs  treats  voices  —  most  use  the  tenn  voice  print  —  as 
a  piece  of  biometric  data,  equal  to  a  fingerprint. 

Role(-)Based  Access  Control 

A  search  for  “role  based  access  control,  which  also  included  a  search 
for  “role-based  access  control,”  returned  59  PIA  documents  referencing  the 
tenn  “role(-)based  access  control.”  All  of  those  59  PIAs  discuss  the  use  of 
role-based  (role  based)  access  controls  to  limit  or  otherwise  manage  access  to 
Department  databases.  The  majority  of  the  PIAs  mentioning  role  based  access 
control,  35,  are  for  DHS  systems.  Most,  if  not  all,  of  the  DHS  PIAs  discussing 
role-based  access  controls  do  so  in  relation  to  protected  databases  containing 
PII  for  security  rather  than  internal/administrative/human-resources  purposes. 

Additionally,  unlike  the  other  departments  refening  to  role  based  ac¬ 
cess  controls  in  their  available  PIAs  (DOJ  [12],  HHS  [3],  DOS  [1],  Depart¬ 
ment  of  the  Treasury/IRS  [8]),  DHS  does  not  define  the  roles  relevant  to  the 
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access  controls,  likely  due  to  the  difference  in  types  of  databases  utiliz¬ 
ing/requiring  role-based  access  controls.  That  is,  the  PIAs  for  DOJ,  HHS, 
DOS,  and  Department  of  the  Treasury/IRS  generally  refer  to  role-based  access 
controls  for  internal/administrative/HR-specific  databases  as  opposed  to  the 
databases  referenced  by  DHS  PIAs. 

Discretionary  Access  Control 

A  search  for  “discretionary  access  control”  returned  nine  PIA  docu¬ 
ments  referencing  the  term.  These  nine  PIA  documents  collected  mention  the 
use  of  discretionary  access  controls  in  the  context  of  limiting  or  otherwise 
managing  access  to  U.S  government  databases.  These  nine  PIAs  come  from 
several  departments,  including  Department  of  the  Treasury  (IRS  and  non- 
IRS),  DOJ,  DOD,  and  the  VA.  The  two  PIAs  from  DOS  mentioning  discre¬ 
tionary  access  control  do  so  only  in  their  list  of  acronyms,  and  should  be  con¬ 
sidered  “false  positives”  for  useful  information. 

Most  of  the  non-FP  PIAs  mentioning  discretionary  access  control  do 
so  without  any  explanation  of  how  said  controls  would  be  applied  and  to 
which  aspect  of  the  system  analyzed  for  the  PIA.  Several  of  the  PIAs  (three) 
noted  only  that  discretionary  access  controls  were  built  into  the  operating  sys¬ 
tems  of  their  computer  systems  —  Windows  2003  and  Windows  NT.  Those 
PIAs  that  did  discuss  the  application  of  discretionary  access  controls  did  so  in 
reference  to  a  type  of  access  control  that  allows  users  of  a  system  to  access 
only  selected  bits  of  information  based  on  pre-set  user  infonnation. 

Mandatory  Access  Control 

A  search  for  the  tenn  “mandatory  access  control”  returned  five  PIA 
documents.  Four  of  the  five  PIA  documents  mentioning  Mandatory  Access 
Controls  are  for  DHS  systems;  the  fifth  comes  out  of  the  IRS.  While  the  IRS 
PIA  does  not  explain  how  said  access  controls  are  applied  or  what  their  pur¬ 
pose  is  (beyond  controlling  access,  of  course),  the  DHS  PIAs  go  into  more 
detail. 
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According  to  the  DHS  PIA  documents  mentioning  the  tenn,  mandatory 
access  controls,  as  opposed  to  discretionary  access  controls,  provide  users  ac¬ 
cess  to  systems  on  a  “demonstrated  need-to-know”  basis,  and  is  enforced  on 
multiple  levels.  Additionally,  the  DHS  PIAs  specify  that  mandatory  access 
controls  specify  that  multiple  approvals  are  needed  for  users  to  gain  or  modify 
their  access  to  systems  with  such  controls  —  a  stronger  level  of  access  control 
than  discretionary  or  role-based  controls.  Overall,  however,  like  discretionary 
access  controls,  mandatory  access  controls  were  not  mentioned  by  even  a 
small  minority  of  PIA  documents. 

DNA 

A  search  for  “DNA”  revealed  27  PIA  documents  mentioning  the  term. 
A  closer  analysis  unearthed  15  false  positives  —  all  from  the  DOJ/FBI,  due  to 
the  way  the  PIAs  were  captured  (in  capturing  PIA  documents  from  HTML,  we 
inadvertently  and  unavoidable  also  capture  extraneous  text,  which  in  this  case 
included  a  link  to  “The  National  DNA  Index  system”  —  a  reference  of  the 
tenn  “DNA”  but  with  no  content-based  relevance  to  the  PIAs  in  question). 

After  discounting  for  the  false  positives,  we  found  12  PIAs  discussing 
federal  government  systems  that  include  the  collection,  storage,  and  dissemi¬ 
nation  of  DNA.  One  of  those  PIAs,  from  the  CDC,  discusses  the  collection  of 
“DNA  fingerprints”  related  to  food-borne  illnesses  (in  humans);  the  remainder 
involves  the  capture  of  DNA  as  PII.  Departments  with  PIAs  mentioning  the 
collection/dissemination  of  DNA  include  DOJ  (the  FBI),  HHS  (CDC,  NIH), 
and  DOS.  The  seven  (7)  DOS  PIAs  mention  DNA  as  one  type  of  PII  poten¬ 
tially  captured  by  each  system.  These  PIAs  do  not  differentiate  between  the 
types  of  PII  captured  by  each  system,  so  we  cannot  conclude  that  these  sys¬ 
tems  necessarily  capture  DNA  as  part  of  their  activities,  only  that  it  is  possi¬ 
ble. 
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Annex  I  Example  Use  and  Misuse  Cases 

I.  USE  CASES  and  Mission  Needs 

•  Federal  Aviation  Administration 

One  of  the  main  functions  of  the  Federal  Aviation  Administration 
(FAA)  is  to  monitor  and  enforce  safety  issues  and  policies  in  all  aspects  of 
civil  aviation  from  plane  maintenance,  pilot  health  and  suitability,  runway  and 
facility  standards,  facility  and  personnel  security,  and  protection  and  mainte¬ 
nance  of  the  National  Airspace.  In  order  to  perfonn  these  missions,  it  is  neces¬ 
sary  to  provide  inspectors  and  special  agents  with  credentialing  that  mandates 
immediate  access  to  certain  secure  areas  such  as  an  airliner  cockpit  or  a  con¬ 
trol  tower.  There  have  been  occasions  where  the  credentials  have  been  lost  or 
misused  for  some  purpose.  Currently,  these  credentials  are  not  smart  enabled. 

In  the  end  state,  the  credentials  are  tied  in  with  the  PIV  card  Authorita¬ 
tive  Database  so  that  if  an  employee’s  PIV  card  is  expired,  suspended,  or  re¬ 
voked,  the  credential  will  be  as  well.  The  credential  will  be  encoded  with 
biometrics  and  a  ccrtificatc(s)  to  facilitate  ‘point  of  presentation’  validation. 
The  PIV  card  itself  may  become  the  credential. 

In  the  end  state,  single  sign-on  will  become  a  reality  with  the  presenta¬ 
tion  of  a  linger  on  a  reader.  The  sign-on  will  be  available  not  only  for  work 
related  systems  (network,  e-mail,  Employee  Express,  TSP,  etc.),  but  will  in¬ 
clude  public  and/or  personal  sites  such  as  personal  email  or  public  sites  related 
to  work. 

Given  the  events  of  9/1 1  and  the  advent  of  the  PIV  card,  there  has  been 
interest  in  requiring  commercial  pilot  licensees  to  have  PIV  type  credentials 
and  to  go  through  some  sort  of  identity  vetting  process  that  is  more  rigorous 
than  what  now  exists.  Beyond  policy  questions  about  the  level  of  vetting  and 
credential  features  there  are  some  major  logistical  issues  that  emerge.  The 
process  of  registration  is  complex.  Where  would  a  pilot  go  to  get  biometrics 
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taken  and  to  submit  proof  of  identity  documents?  It  is  not  feasible  for  the  FAA 
to  have  personnel  at  every  commercial  airport. 

In  the  end  state,  the  applicant  pilots,  or  anyone  who  needs  to  prove 
identity  in  order  to  interact  with  government  services,  would  report  to  a 
‘trusted  agent’  of  some  sort  who  would  collect  biometric  and  identity  proofing 
information.  This  data  would  be  processed  to  the  level  of  vetting  deemed  nec¬ 
essary  for  the  citizen’s  requested  service  and  approved  by  the  deliverer  of  that 
service. 


These  are  some  of  the  many  major  issues  that  need  to  be  addressed: 

1 .  Where  does  the  citizen  go  to  register?  Perhaps  the  trusted  agent 
would  be  the  local  post  office?  A  kiosk  in  a  mall? 

2.  How  does  the  ‘trusted  agent’  submit  the  application?  How  does  he 
know  where  to  send  it  if  he  is  a  trusted  agent  for  multiple  agen¬ 
cies? 

3.  How  does  the  citizen  receive  the  credential?  Self  activation? 

•  Department  of  Defense 

Successful  Battlefield  Medical  Care  depends  upon  several  factors,  to 
include  accurate  baseline  knowledge  of  certain  individual  physiological  quali¬ 
ties,  archived  since  original  accession  (e.g.,  blood  type,  allergies);  accurate 
and  timely  knowledge  of  the  nature  of  wounds,  injuries  or  illnesses  as  they 
occur;  and  knowledge  of  the  location  and  capabilities  of  medical-response 
providers  and  facilities,  both  in  the  immediate  area,  and  at  more  remote  loca¬ 
tions,  depending  on  the  specific  need,  and  progress  of  treatment. 

Knowledge  of  the  medical  history  of  military  and  other  attached  gov¬ 
ernment  personnel  (any  of  whom  can  quickly  become  ‘patients’);  of  the  avail¬ 
ability,  skills,  qualifications  and  locations  of  medical  personnel;  and  of  the 
facilities  where  care  can  be  provided,  key  supplies  or  medicines  located,  or 
specific  procedures  performed,  are  all  uniquely  identifiable  and 
“known.”However,  these  data  are  archived  in  disparate  data  bases  and  sys¬ 
tems,  in  many  locations.  While  some  aspects  of  identity  needed  to  support 
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healthcare  are  predictable,  such  that  data  can  be  pre-staged,  others  are  dy¬ 
namic,  and  reactive  to  battlefield  conditions  that  may  develop  suddenly.  Ulti¬ 
mately,  the  goal  of  fully-responsive,  full-scope  medical  care  remains  the  same: 
Be  able  to  access  “all”  baseline  physiology  and  medical  history  data,  for  “all” 
military  personnel,  “everywhere”  at  “all  times,”  and  make  these  available  to 
“all”  proper  medical  responders,  wherever  located,  even  as  the  patient  may  be 
moved  from  place  to  place  to  facilitate  optimal  care... The  additional  factor  of 
the  protections  mandated  by  law  relative  to  personal  medical  history  and  re¬ 
cords  complicates  the  process  by  adding  requirements  for  security  and  ac¬ 
countability  to  the  transmission,  storage  and  use  of  such  private  and  personal 
information. 

Information- techno  logy  networks  must  be  able  to  access  patients,  re¬ 
sponding  practitioners  (including  remote  experts  for  consultation  or  telemedi¬ 
cine  purposes)  and  relevant  archival  data  about  individuals  and  medical 
science.  These  nets  must  serve  “everybody,  everywhere,”  providing  secure, 
auditable  and  private  information  exchange  that  associates  unique  individuals 
and  information  with  accuracy,  confidence  and  efficiency.  The  unique  “identi- 
fiability”  of  all  parties  to  these  processes,  each  within  their  different  roles  and 
privileges,  makes  this  all  possible,  if  the  network  also  possesses  all  needed 
capabilities  and  features  to  support  high-demand,  critical  identity  transactions 
in  complete  security. 


•  Federal  Bureau  of  Investigation 

Employees  of  the  Federal  Bureau  of  Investigation  (FBI)  are  required  to 
track  time,  attendance,  and  leave  usage  electronically  via  WebTA.  WebTA  re¬ 
placed  the  FBI’s  paper-based  collection  system  with  a  commercial  off-the- 
shelf  product  providing  Bureau  employees  with  an  online,  Web-based  system 
to  record  their  time  and  attendance  (TA)  data.  The  WebTA  system  interfaces 
with  several  legacy  FBI  systems  and  generates  an  automated  interface  with 
the  National  Finance  Center.  Although  this  solution  improves  the  efficiency  of 
the  TA  process  and  reduces  the  overall  personnel  costs  associated  with  TA, 
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there  are  still  other  systems  that  WebTA  could  interface  with  to  further  stream¬ 
line  the  process.  One  such  system  is  the  stand-alone  system  that  captures  arri¬ 
val  times  via  the  PKI  access  card. 


The  end  state  of  IdM  would  enable  data  sharing  between  these  two 
stand-alone  systems,  thereby  allowing  the  automated  population  of  arrival  and 
departure  times  based  on  the  time  employees  enter  and  leave  the  premises. 

Furthermore,  multiple  systems  exist  that  employees  access  in  the  daily 
performance  of  their  duties.  Each  of  these  systems  are  accessed  with  user- 
names  and  passwords.  Passwords  are  changed  periodically  for  each  system. 
Additionally,  there  are  multiple  password  requirements  for  each  system,  and 
accounts  are  frequently  suspended  due  to  failed  log-on  attempts. 

The  end  state  of  IdM  would  enable  a  single  sign-on  protocol,  thereby 
allowing  enterprise  network  users  to  seamlessly  access  all  authorized  network 
resources  on  the  basis  of  a  single  authentication  performed  when  they  initially 
access  the  network.  This  architecture  would  improve  the  productivity  of  net¬ 
work  users,  reduce  the  cost  of  network  operations,  and  improve  network  secu¬ 
rity. 


•  Federal  Trade  Commission 

Employees  of  the  Federal  Trade  Commission  (FTC)  are  required  to 
have  usernames  and  passwords  for  numerous  unique  and  independent  sys¬ 
tems.  Employees  are  required  periodically  to  change  their  passwords  for  these 
various  systems.  Thus  an  employee  may  have  as  many  as  eight  separate  pro¬ 
tocols  and  passwords  for  the  various  systems.  These  systems  include  the  fol¬ 
lowing: 

1 .  Logging  on  to  the  FTC  network; 

2.  The  staff  time  and  activity  reporting  (STAR)  system,  where  staff 
record  the  matters  they  are  working  on  and  the  amount  of  time 
spent  on  each; 
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3.  Consumer  Sentinel,  the  FTC’s  database  of  consumer  complaints; 

4.  FedTraveler,  the  government-wide  program  used  to  make  travel  ar¬ 
rangements  for  employees  (administered  by  a  separate  agency); 

5.  Employee  Express,  used  by  employees  to  track  their  pay  and  benefits 
(administered  by  the  Office  of  Personnel  Management); 

6.  The  Thrift  Savings  Plan  (TSP),  employees’  retirement  plan  (adminis¬ 
tered  by  the  Federal  Retirement  Thrift  Investment  Board); 

7.  The  Time  and  Attendance  program;  and 

8.  Westlaw  and  LexisNexis,  programs  used  for  legal  research. 


The  end  state  of  IdM  should  enable  a  single  sign-on  protocol.  In  other 
words,  employees  would  be  able  to  sign  on  to  the  network  and  have  access  to 
all  of  the  systems  listed  to  which  they  have  authorized  access,  both  those  ad¬ 
ministered  by  the  FTC  as  well  as  those  administered  by  other  agencies.  This 
single  sign-on  protocol  end  state  system  may  not  be  feasible  for  systems  run 
outside  the  government,  such  as  Westlaw  and  LexisNexis. 


•  Supply  Chain  Management39 

This  topic  is  not  specific  to  any  federal  organization,  but  a  matter  of 
general  concern.  The  Government’s  infonnation  technology  systems  are  es¬ 
sential  to  the  successful  implementation  of  electronic  identity  management. 
These  systems  are  at  increasing  risk  of  supply  chain  attacks  from  adversaries 
enabled  by  their  growing  technological  sophistication  and,  more  importantly, 


39  Excerpted  from  the  Executive  Summary  of  the  Committee  for  National  Security  Systems. 
Framework  for  Lifecycle  Risk  Mitigation  for  National  Security  Systems  in  the  Era  of 
Globalization.  CNSS  Report:  145-06.  November  2006,  pp  ES-1  -  ES-3. 
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facilitated  by  the  rapid  globalization  of  the  infonnation  technology  (IT)  mar¬ 
ketplace. 

Supply  chain  attacks  involve  manipulating  IT  hardware,  software,  op¬ 
erating  systems,  peripherals  (“IT  products”),  or  services  at  any  point  during 
the  life  cycle  to  provide  access  when  the  product  is  delivered  to  the  user.  Sup¬ 
ply  chain  attacks  are  typically  conducted  or  facilitated  by  individuals  or  or¬ 
ganizations  that  have  access  to  the  products  through  commercial  ties. 

Whereas  the  federal  government  has  traditionally  been  able  to  rely  on 
U.S. -based  hardware  and  software  suppliers  and  U.S. -based  network  opera¬ 
tors,  globalization  is  rapidly  undermining  many  of  the  assumptions  concerning 
supply  chain  integrity  on  which  we  could  previously  rely.  Now,  many  suppli¬ 
ers  are  offshore,  and  even  U.S. -based  companies  use  research  and  manufactur¬ 
ing  facilities  elsewhere  for  much  of  their  work.  Mergers  and  acquisitions  have 
changed  the  ownership  and  management  of  many  non-government  telecom¬ 
munication  and  IT  infrastructures,  placing  foreign  companies  in  ultimate  con¬ 
trol  of  even  domestic  operations. 

Globalization  and  its  consequences  are  permanent  and  irreversible  and 
are  likely  to  have  only  greater  impact  over  time. 

The  Defense  Science  Board’s  Task  Force  on  High  Performance  Chip 
Supply,  published  in  February  2005,  reported  on  such  trends  as  they  affect  on¬ 
ly  one  part  of  the  overall  IT  industry.  The  findings  exemplify  the  problem  of 
globalization.  One-sixth  of  the  U.S.  chip  industry  no  longer  has  fabrication 
facilities,  and  U.S.  industry’s  share  of  capital  expenditures  in  leading  edge 
semiconductor  manufacturing  capacity  has  fallen  from  36  percent  in  1999  to 
only  20  percent  in  2004. 40  The  Task  Force  concluded,  “This  [horizontal  con¬ 
solidation  of  chip  fabrication,  mask  making...]  has  led  to  global  dispersion  of 


40 

Defense  Science  Board  Task  Force,  High  Performance  Microchip  Supply,  February  2005, 
pp.  19-21. 
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manufacturing  operations,  removing  many  critical  operations  from  U.S.  na¬ 
tional  control.” 

Moreover,  infonnation  and  telecommunications  technologies  are 
quickly  converging  and,  therefore,  becoming  ever  more  interconnected — and 
ever  more  exposed  to  potential  vulnerabilities.  Not  only  is  the  changing  face 
of  vendors  requiring  the  federal  government  to  rethink  its  infonnation  assur¬ 
ance  policies,  but  also  those  very  telecommunication  structures  are  undergo¬ 
ing  fundamental  changes  affecting  how  the  federal  government  can  design  its 
protective  measures. 

It  is  impractical,  if  not  impossible,  to  avoid  the  risks  of  globalization 
by  trying  to  insulate  the  federal  government  from  its  effects.  Instead,  there  are 
four  identified  goals  for  mitigating  risk: 

•  Enhance  the  security  and  resilience  of  federal  government  IT  and  tel¬ 
ecommunication  infrastructures, 

•  Identify  and  mitigate  opportunities  for  exploitation, 

•  Increase  adversaries’  cost  and  risk  of  exposure,  and 

•  Reduce  adversaries’  confidence  that  an  attack  will  be  effective. 

The  traditional  approach  focuses  on  protecting  the  network  and  atten¬ 
dant  infrastructures  through  layered  defenses  (e.g.,  firewalls,  intrusion  detec¬ 
tion  systems,  public  key  infrastructure,  and  cryptography);  however,  this  is  not 
sufficient  to  mitigate  risk  arising  from  increasing  globalization  and  the  in¬ 
creasing  sophistication  of  adversaries.  Given  this  reality,  any  successful  strat¬ 
egy  must  be  comprehensive  and  extend  across  the  product  life  cycle.  It  must 
identify  each  life  cycle  phase  of  a  product  and  also  each  person  or  organiza¬ 
tion  with  either  authorized  or  possible  unauthorized  access  to  the  product  at 
each  phase  where  vulnerability  could  be  exploited.  An  approach  that  depends 
too  much  on  protection  at  one  point,  or  through  one  evaluation,  or  from  one 
type  of  organization,  will  simply  lead  adversaries  to  look  elsewhere  for  a 
weakness  they  can  exploit.  The  only  way  to  meet  increasing  sophistication 
and  globalization  is  to  develop  a  broad-based  response. 
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To  achieve  reasonable  assurance  in  the  integrity  of  the  supply  chain, 
the  risk  of  vulnerability  must  be  identified,  managed,  or  eliminated  at  each 
lifecycle  phase  listed  below. 

•  Product  design  and  development, 

•  Manufacturing, 

•  Packaging, 

•  Assembly, 

•  System  integration, 

•  Distribution, 

•  Operations, 

•  Maintenance,  and 

•  Retirement. 


This  comprehensive  approach  provides  a  proactive,  rather  than  reac¬ 
tive,  strategic  framework  for  lifecycle  risk  mitigation  of  supply  chain  attacks. 

•  National  Security  Screening 

Federal  requirements  for  screening  of  persons  for  the  purpose  of  coun¬ 
tering  terrorism  are  found  in  a  number  of  Presidential-level  directives,  e.g.,: 

•  Homeland  Security  Presidential  Directive/HSPD-6 
(“Integration  and  Use  of  Screening  Information”).  This  directive 
establishes  procedures  to: 

(1)  develop,  integrate,  and  maintain  thorough,  accurate,  and  current 
information  about  individuals  known  or  appropriately  suspected  to 
be  or  have  been  engaged  in  conduct  constituting,  in  preparation 
for,  in  aid  of,  or  related  to  terrorism  (Terrorist  Infonnation);  and 

(2)  use  that  information  as  appropriate  and  to  the  full  extent  per¬ 
mitted  by  law  to  support  (a)  federal,  state,  local,  territorial,  tribal, 
foreign-government,  and  private-sector  screening  processes,  and 
(b)  diplomatic,  military,  intelligence,  law  enforcement,  immigra¬ 
tion,  visa,  and  protective  processes. 

•  Homeland  Security  Presidential  Directive/HSPD- 1 1 
(“Comprehensive  Terrorist-Related  Screening  Procedures”).  This 
directive  seeks  to: 

(1)  Enhance  terrorist-related  screening... through  comprehensive, 
coordinated  procedures  that  detect,  identify,  track,  and  interdict 
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people,  cargo,  conveyances,  and  other  entities  and  objects  that  pose 
a  threat  to  homeland  security,  and  to  do  so  in  a  manner  that  safe¬ 
guards  legal  rights,  including  freedoms,  civil  liberties,  and  infor¬ 
mation  privacy  guaranteed  by  federal  law,  and  builds  upon  existing 
risk  assessment  capabilities  while  facilitating  the  efficient  move¬ 
ment  of  people,  cargo,  conveyances,  and  other  potentially  affected 
activities  in  commerce;  and 


(2)  Implement  a  coordinated  and  comprehensive  approach  to  ter¬ 
rorist-related  screening  —  in  immigration,  law  enforcement,  intel¬ 
ligence,  counterintelligence,  and  protection  of  the  border, 
transportation  systems,  and  critical  infrastructure  —  that  supports 
homeland  security,  at  home  and  abroad. 

These  directives  are  readily  accessible  and  may  be  studied  in  full. 
However,  detailed  procedures  regarding  the  actual  conduct  of  screening  op¬ 
erations  are  generally  too  sensitive  to  be  included  in  this  report. 

•  Department  of  State 

The  Department  of  State  is  responsible  for  the  worldwide  diplomatic 
mission  for  the  United  States.  In  this  role,  the  Department  operates  a  global 
information  technology  (IT)  infrastructure  that  must  provide  confidentiality 
and  integrity,  while  operating  at  a  high  level  of  availability.  In  order  to  per¬ 
form  its  mission,  the  Department  must  be  able  to  easily  and  securely  access  a 
wide  range  of  data  and  materials  on  the  Sensitive  but  Unclassified  network. 
Strong  authentication  protocols  ensure  that  this  mandate  is  feasible  and  that 
sensitive  data  is  properly  protected.  The  Department’s  Public  Key  Infrastruc¬ 
ture  (PKI)  and  associated  biometric  logon  capability  provide  enhanced  levels 
of  security  and  user  authentication  to  this  critical,  global  network. 

The  Department  implemented  its  first  PKI  over  half  a  decade  ago.  That 
PKI  provided  the  platform  on  which  other  PKIs  have  been  built,  providing  a 
constantly  widening  range  of  features  and  security.  The  current  functionality  is 
very  broad.  A  PKI  on  the  Active  Directory  based  network  (the  AD  PKI)  that 
enables  both  encryption  and  digital  signature  for  users  at  the  desktop  level  is 
currently  available.  This  same  PKI  provides  the  ability  for  the  Department  to 
sign  mobile  code  and  provides  an  infrastructure  to  enable  a  high-assurance 
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logon  process  for  applications.  The  PIV  PKI  currently  provides  certificates 
that  can  be  used  in  the  authentication  process  with  other  government  agencies. 
Further,  the  Machine  Readable  Travel  Document  (MRTD)  PKI  provides  the 
infrastructure  that  enables  the  digital  signing  of  data  on  the  new  electronic 
passports. 

Coupled  to  the  AD  PKI  is  the  use  of  integrated  biometrics  for  user  au¬ 
thentication.  This  sophisticated  process  uses  match-on-card  technology,  which 
provides  one-to-one  matching  of  the  minutia  on  the  smart  ID  to  the  fingerprint 
presented  by  the  user.  Such  a  process  eliminates  the  network  latency  associ¬ 
ated  with  a  one-to-many  match  in  a  network  database,  both  enhancing  logon 
speed  and  significantly  improving  the  security  of  the  biometric.  Besides  the 
higher  level  of  assurance  associated  with  a  biometric  logon,  this  process  also 
eliminates  the  need  to  remember  passwords  for  system  logon.  Applications 
that  are  integrated  can  also  use  the  same  biometric  logon,  further  enhancing 
the  ease  of  use  for  users  and  improving  network  security.  This  is  a  win  for  all. 

Unfortunately,  full  deployment  of  both  PKI  and  biometrics  has  been 
delayed  due  to  budget  constraints.  Consequently,  this  technology  has  not  yet 
matured  in  the  Department  in  terms  of  broad  acceptance  and  use.  The  end 
state  for  the  Department  should  include  a  complete  deployment  of  PKI  and 
biometric  logon  capabilities  to  all  desktops.  This  final  level  of  deployment 
would  enable  security  functionality  such  as  full  digital  signing  of  all  e-mail 
traffic.  It  would  also  provide  single  sign-on  for  a  wide  range  of  applications, 
further  enhancing  and  securing  the  network  environment.  The  ultimate  elimi¬ 
nation  of  numerous  complex  passwords  will  certainly  make  users  happier  and 
eliminate  the  typical  security  holes  that  invariably  exist  with  passwords. 

•  National  Science  Foundation 

The  National  Science  Foundation  conducts  about  5000  meetings  each 
year  to  evaluate  proposals  for  research  and  education.  Each  of  these 
meetings  occupies  the  time  of  10  to  20  outside  subject  matter  experts 
(who  we  call  reviewers)  for  1  to  3  days.  Of  course,  the  success  of  the 
meetings  depends  greatly  on  who  we  invite,  and  their  willingness  to  at- 
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tend  depends  on  their  past  experiences.  Since  our  reviewer  pool  is  our 
most  valuable  resource  for  distinguishing  high-quality  projects,  we  try  to 
ensure  a  positive  experience  for  every  reviewer  every  time. 

Reviewer  recruitment  and  management  is  currently  a  multistep  proc¬ 
ess: 

1.  Currently  a  program  director  will  start  with  an  idea  of  the  subject  mat¬ 
ter  expertise  required  for  a  particular  review  meeting,  and  will  search  for 
reviewers  using  a  combination  of  internal  and  external  databases. 

2.  Having  found  a  reviewer,  the  program  director  makes  initial  contact 
with  the  reviewer  to  determine  availability  and  interest,  then  passes  the 
names  of  available  reviewers  to  a  program  assistant. 

3.  The  program  assistant  checks  the  names  for  membership  in  our  inter¬ 
nal  reviewer  database,  and  contacts  those  reviewers  who  are  new  to  our 
database  for  addresses,  phone  numbers,  email  addresses,  and  other  in¬ 
formation. 

4.  Once  the  meeting  roster  is  complete  the  program  assistant  prepares 
group  travel  orders  and  sends  email  to  the  reviewers  with  instructions  for 
arranging  travel. 

5.  Meanwhile,  the  program  director  sends  a  list  of  proposals  to  be  re¬ 
viewed  and  review  instructions  to  each  reviewer.  The  program  director 
also  asks  each  reviewer  to  note  any  existing  relationships  that  might  pose 
ethical  problems  in  evaluating  proposals.  The  program  director  and  pro¬ 
gram  assistant  set  up  an  electronic  reviewing  system  to  be  used  on  the 
day  of  the  meeting,  specifying  the  role  of  each  reviewer  with  regard  to 
each  proposal. 

6.  Reviewers  arrange  their  own  travel  using  FedTraveller.  NSF  staff 
stands  by  to  help. 
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7.  On  the  day  of  the  meeting,  reviewers  sign  in  and  conduct  business  us¬ 
ing  the  electronic  reviewing  system.  They  must  at  this  time  fill  out  a  di¬ 
rect-deposit  form  and  give  us  their  SSNs  so  that  we  can  reimburse  their 
expenses  and  pay  a  consulting  fee. 

8.  Once  the  meeting  is  over,  information  on  the  reviewers  is  sent  to  our 
financial  division  which  begins  arranging  payment. 

9.  The  program  director  notes  the  performance  and  expertise  of  each  re¬ 
viewer  to  aid  in  organizing  later  meetings.  This  information  may  be  kept 
privately  or  (rarely)  may  be  entered  into  the  NSF  internal  review  data¬ 
base. 

10.  Two  to  six  weeks  after  reviewers  return  home  most  are  reimbursed. 
Those  that  are  not  or  who  have  some  problems  get  in  touch  with  the  pro¬ 
gram  director  and  assistant,  who  work  with  other  parts  of  NSF  to  resolve 
the  issues. 

1 1 .  Several  months  after  the  meeting,  issues  have  been  resolved  and  all 
reviewers  have  been  paid. 

Several  of  the  steps  above  could  be  simplified  or  eliminated  in  the  end 
state  of  identity  management.  If  a  reviewer  has  served  NSF  before,  there  is  no 
need  to  collect  redundant  information,  eliminating  steps  3,  part  of  7,  8,  and  11. 
We  could  have  the  travel  system  suggest  an  itinerary  and  hotel  based  on  past 
choices,  eliminating  step  6.  We  could  eliminate  the  multiple  entries  into  our 
silos  and  greatly  reduce  the  errors  that  arise  from  transferring  infonnation  ma¬ 
nually  between  systems.  If  this  reviewer  process  were  integrated  with  our  pro¬ 
posal  and  award  process,  we  could  automate  other  aspects  of  this  work,  for 
example  by  finding  reviewers  who  currently  had  projects  ongoing  that  were 
similar  to  the  one  proposed,  easing  step  1 . 
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II.  MISUSE  CASES  -  Activities  and  behaviors  to  be  detected  and 


prevented. 


•  Disclosure  of  identifier  information.  The  IdM  system  could  improperly 
disclose  identifier  information  to  a  third  party.  This  may  be  carried  out  by 
a  man-in-the-middle  attack,  where  a  malefactor  inserts  itself  into  the 
communication  path  between  a  user  and  the  system,  spoofs  messages  both 
ways,  and  captures  information  intended  for  the  system.  It  may  be  carried 
out  by  spyware  or  other  malware  inserted  into  the  user’s  computer  or  into 
the  IdM  server.  It  may  be  carried  out  by  social  engineering,  in  which  a  ma¬ 
lefactor  convinces  a  human  involved  with  the  IdM  system  to  disclose  in¬ 
formation,  perhaps  under  a  pretense  of  a  forgotten  password. 

•  Use  of  disclosed  identifier  information.  Once  disclosed,  the  identifier 
information  can  be  used  improperly.  This  could  be  used  to  gather  further 
information  on  the  user,  to  change  information  about  the  user,  to  deny  ac¬ 
cess  to  the  user,  or  to  spoof  interactions  with  either  people  or  IdM  systems 
in  the  federation. 

•  Identifier  information  held  by  adversaries  and  partners.  Other  entities 
will  hold  information  on  U.S.  persons,  and  could  use  that  information  to 
improperly  access  U.S.  IdM  systems.  This  could  come  from  entry  records 
into  foreign  countries,  from  purchased  credit  bureau  reports,  or  from  sepa¬ 
rate  IdM  systems  that  collect  the  same  information  as  the  U.S.  ones.  It  is 
conceivable  that  a  trusted  partner  could  in  the  future  become  an  adversary 
and  misuse  information  that  had  been  shared  during  the  partnership.  A 
partner  might  have  a  less  secure  IdM  system  than  the  government,  in 
which  case  infonnation  might  be  disclosed  by  the  partner. 
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Annex  J  International  Standards  Organizations  Involved  in 
IdM 

In  the  area  of  technical  IdM  standards  to  achieve  global  interoperabil¬ 
ity,  two  of  the  most  active  are  the  International  Telecommunication  Union 
(ITU)  and  the  International  Organization  for  Standardization  (ISO).  In  the  area 
of  developing  non-technical  IdM  policies,  the  Organization  for  Economic  Co¬ 
operation  and  Development  (OECD)  has  begun  to  play  a  role.  It  should  be 
noted  that  in  addition  to  these  organizations,  there  are  several  commercial  ef¬ 
forts  underway  to  develop  IdM  standards.  However,  because  this  report  is  fo¬ 
cused  on  the  federal  government  scope  cited  at  the  outset,  the  various 
commercial  IdM  initiatives  are  not  addressed.  The  only  exception  is  the  ISO, 
discussed  below,  where  there  is  significant  federal  participation. 

The  International  Telecommunication  Union.  The  International  Tel¬ 
ecommunication  Union  (ITU)  is  a  UN  agency  that  is  distinguished  from  other 
standards  development  organizations  by  the  fact  that  its  membership  formally 
includes  both  national  administrations  and  the  private  sector.  There  are  cur¬ 
rently  about  191  Member  States  and  more  than  700  private  sector  members  in 
the  ITU.  The  ITU  is  organized  into  a  Radiocommunication  Sector  (ITU-R),  a 
Telecommunication  Sector  (ITU-T),  and  a  Development  Sector  (ITU-D).  The 
ITU-T  has  several  IdM  standards  (known  as  Recommendations)  under  devel¬ 
opment,  and  has  recently  completed  development  of  a  Recommendation  on 
“Requirements  for  global  identity  management  trust  and  interoperability,” 
X.1250.  This  recommendation  is  now  in  the  process  of  being  approved  by 
ITU  members. 

X.1250  provides  a  structured  set  of  requirements  for  capabilities  nec¬ 
essary  for  global  IdM  trust  and  interoperability,  i.e.,  to  enable  known  trust  in 
the  assertions  about  digital  identities  (credentials,  identifiers,  attributes  and 
reputations)  used  in  all  communication  and  control  networks  and  services.  It 
will  be  in  the  ITU-T  approval  process  until  September  2008.  It  is  the  first 
global  intergovernmental-industry  standard  of  its  kind,  and  provides  the  core 
definitions  and  framework  for  all  subsequent  ITU-T  IdM  recommendations. 
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A  structured  set  of  requirements  for  capabilities  necessary  for  global 
IdM  trust  and  interoperability  is  essential  to  enable  known  trust  in  the  asser¬ 
tions  about  digital  identities  (credentials,  identifiers,  attributes  and  reputa¬ 
tions)  used  in  all  communication  and  control  networks  and  services.  The  use 
of  the  tenn  “global”  here  refers  to  both  worldwide  geography,  as  well  as  ap¬ 
plicability  to  the  entire  array  of  telecommunication/ICT  networks  and  ser¬ 
vices. 


The  implementation  of  IdM  among  governmental  and  private-sector 
networks  and  services  will  remain  very  diverse,  highly  distributed,  substan¬ 
tially  autonomous,  and  constantly  evolving.  This  dynamic  diversity  was  a 
consideration  in  defining  these  requirements.  The  specification  includes  avail¬ 
able  references  to  best  practices  for  the  protection  of  personally  identifiable 
information. 

The  specification  comprises  nine  sections  of  essential  requirements: 

1 .  A  common  identity  management  model. 

2.  An  interoperable  set  of  IdM  functions. 

3.  Establishes  four  basic  Identity  Services:  credential,  identi¬ 
fier,  attribute,  and  reputation  identity  services  with  known  as¬ 
surance  levels  to  all  entities. 

4.  Discovery  of  authoritative  identity  provider  resources,  ser¬ 
vices,  and  Federations. 

5.  Interoperability  and  bridging. 

6.  Security  and  policy. 

7.  Auditing  and  compliance. 

8.  Performance,  reliability,  availability. 

9.  Internationalization. 

As  noted,  this  standard  has  not  been  finally  adopted  by  the  entire  in¬ 
ternational  community,  and  the  U.S.  government  will  need  to  carefully  study 
the  adoption  of  its  precepts,  in  consideration  of  the  complexity  of  the  current 
IdM  architecture  and  future  needs.  In  any  case,  it  is  clear  at  the  outset  that  the 
emergence  of  this  proposal  represents  a  pivotal  development  in  the  progress  of 
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global  IdM,  inasmuch  as  it  represents  the  topic  in  a  truly  universal  way,  for  the 
first  time,  across  the  international  community. 

The  International  Organization  for  Standardization  (ISO).  The 

ISO  is  the  world’s  largest  standards  development  organization.  Although  its 
membership  is  organized  along  national  lines,  member  states  are  represented 
by  national  standards  bodies  referred  to  as  technical  advisory  groups.  The 
American  National  Standards  Institute  (ANSI)  is  the  United  States  technical 
advisory  group  to  ISO. 

ISO’s  standardization  program  covers  a  wide  variety  of  subjects,  in¬ 
cluding  Information  Technology.  The  Information  Technology  work  is  under 
the  auspices  of  Joint  Technical  Committee  One  (JTC1)  for  which  ANSI  serves 
as  Secretariat.  JTC 1  has  a  number  of  subcommittees  addressing  telecommuni¬ 
cations  and  IdM.  Among  other  subcommittees,  the  following  three  should  be 
of  interest  to  any  federal  government  IdM  undertaking. 

•  ISO/IEC  JTC  1  Sub  Committee  17  —  Responsible  for  all  identifi¬ 
cation  cards  and  related  interface  and  device  standards. 

•  ISO/IEC  JTC  1  Sub  Committee  27  —  Responsible  for  security 
and  privacy  technology  standards. 

•  ISO/IEC  JTC  1  Sub  Committee  37  —  Responsible  for  biometric 
standards 

It  is  customary  for  ISO  and  ITU-T  to  coordinate  the  preparation  and 
publication  of  documents  where  there  is  sufficient  common  interest  and 
work. 

The  Organization  for  Economic  Co-operation  and  Development. 

In  the  multilateral  context,  one  organization  that  develops  non-technical  poli¬ 
cies  is  the  OECD.  The  OECD  is  a  forum  in  which  the  governments  of  thirty 
member  countries  (including  the  United  States)  address  the  economic,  social, 
environmental,  and  governance  challenges  and  opportunities  of  the  globaliz¬ 
ing  world  economy.  Non-members  such  as  business,  civil  society,  and  other 
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international  organizations  also  attend  and  provide  input  and  advice.  One  of 
the  OECD  committees  is  the  Committee  for  Information,  Computer  and 
Communications  Policy  (ICCP).  The  Working  Party  on  Information  Security 
and  Privacy  (WPISP)  is  a  subgroup  that  works  under  the  ICCP’s  direction. 
The  WPISP’s  terms  of  reference  include  the  following: 

‘To  monitor  and  analyze  developments  and  trends  in  security  of  infor¬ 
mation  systems  and  networks,  and  protection  of  personal  data  and  privacy  in 
the  Digital  Economy /Global  information  society  and  to  develop  and  propose 
policy  options  for  security  of  information  systems  and  networks,  and  protec¬ 
tion  of personal  data  and  privacy/'’ 
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Annex  K  Identity  Management  Glossary 


This  glossary  is  largely  copied  from  the  one  adapted  and  used  in  the 
development  of  the  ITU’s  IdM  standards.  It  was  selected  for  the  TF’s  purposes 
due  to  its  currency,  international  and  government/industry  scope,  and  gener¬ 
ally  comprehensive  nature.  Even  so,  the  TF  did  add  a  few  terms,  as  used  or 
adapted  herein.  Also,  two  definitions  were  changed  to  conform  to  current  fed¬ 
eral  standards:  “Biometrics,”  as  used  in  the  NSTC  Subcommittee  on  Biomet¬ 
rics  and  Identity  Management,  inter  alia;  and  “PH,”  as  used  by  the  Office  of 
Management  and  Budget. 


Term 

Definition(s) 

access  control 

The  prevention  of  unauthorized  use  of  a  resource,  including 
the  prevention  of  use  of  a  resource  in  an  unauthorized  manner. 

address 

An  address  is  the  identifier  for  a  specific  termination  point  and 
is  used  for  routing  to  this  termination  point. 

agent 

A  computer  system  or  device  that  has  been  delegated  (author¬ 
ity,  responsibility,  a  function,  etc.)  by  and  acts  for  a  Party  (in 
exercising  the  authority,  carrying  out  the  responsibility,  per¬ 
forming  the  function,  etc.). 

alliance 

An  agreement  between  two  or  more  independent  Entities  that 
defines  how  they  will  relate  to  each  other  and  how  they  jointly 
conduct  activities. 

anonymity 

i.  Ability  to  allow  anonymous  access  to  services,  which 
avoid  tracking  of  user's  personal  information  and  user  be¬ 
haviour  such  as  user  location,  frequency  of  a  service  usage, 
and  so  on. 

ii.  Lack  of  any  capability  to  ascertain  identity. 

iii.  The  quality  or  state  of  being  anonymous,  which  is  the 
condition  of  having  a  name  or  identity  that  is  unknown  or 
concealed. 

assertion 

i.  A  representation  of  an  entity’s  identity  or  claim. 

(Compare  with  manifestation.) 

ii.  The  identity  information  provided  by  an  Identity  Pro¬ 
vider  to  a  Service  Provider. 

asserting  identity 

An  entity  making  an  identity  representation  or  claim  to  a  re¬ 
lying  party  within  some  request  context. 
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Term 

)efinition(s) 

asset 

Anything  that  has  value  to  the  organization,  its  business,  its 
operations  and  its  continuity. 

assurance  (or  at  least 
authentication  as¬ 
surance) 

A  measure  of  confidence  that  the  security  features  and  archi¬ 
tecture  of  the  Identity  Management  capabilities  accurately 
mediate  and  enforce  the  security  policies  understood  between 
the  Relying  Party  and  the  Identity  Provider. 

assurance  level 

A  quantitative  expression  of  Assurance  agreed  between  a  Re¬ 
lying  Party  and  an  Identity  Provider. 

asymmetric  authen¬ 
tication  method 

A  method  of  authentication,  in  which  not  all  authentication 
information  is  shared  by  both  entities. 

attribute 

i.  Descriptive  information  bound  to  an  entity  that  speci¬ 
fies  a  characteristic  of  an  entity  such  as  condition,  quality 
or  other  information  associated  with  that  entity 

ii.  Information  of  a  particular  type.  In  the  IdM,  objects  and 
object  classes  are  composed  of  attributes. 

iii.  A  distinct  characteristic  of  an  object.  An  object's  attrib¬ 
utes  are  said  to  describe  the  object.  Objects'  attributes  are  of¬ 
ten  specified  in  terms  of  their  physical  traits,  such  as  size, 
shape,  weight,  and  color,  etc.,  for  real-world  objects.  Objects 
in  cyberspace  might  have  attributes  describing  size,  type  of 
encoding,  network  address,  etc. 

attribute  type 

That  component  of  an  attribute  which  indicates  the  class  of 
information  given  by  that  attribute. 

attribute  value 

A  particular  instance  of  the  class  of  information  indicated  by 
an  attribute  type. 

audit  (secret) 

An  independent  review  and  examination  of  system  records 
and  activities  in  order  to  test  for  adequacy  of  system  controls, 
to  ensure  compliance  with  established  policy  and  operational 
procedures,  to  detect  breaches  in  security,  and  to  recommend 
any  indicated  changes  in  control,  policy  and  procedures. 

authenticated  iden¬ 
tity 

A  distinguishing  identifier  of  a  principal  that  has  been  as¬ 
sured  through  authentication. 

authentication 

The  provision  of  assurance  of  the  claimed  identity  of  an  en¬ 
tity. 

authentication  cer¬ 
tificate 

A  security  certificate  that  is  guaranteed  by  an  authentication 
authority  and  that  may  be  used  to  assure  the  identity  of  an 
entity. 

authentication  ex¬ 
change 

A  sequence  of  one  or  more  transfers  of  exchange  authentica¬ 
tion  information  (AI)  for  the  purposes  of  performing  an  au¬ 
thentication. 
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Term 

)efinition(s) 

authentication  in¬ 
formation 

i.  Information  used  to  establish  the  validity  of  a  claimed 
identity. 

ii.  Information  used  for  authentication  purposes. 

authentication  initia¬ 
tor 

The  entity  that  starts  an  authentication  exchange. 

authorization 

The  granting  of  rights,  which  includes  the  granting  of  access 
based  on  access  rights. 

authoritative  identity 
provider 

The  Identity  Provider  responsible  by  law,  industry  practice, 
or  system  implementation  for  the  definitive  identity  response 
to  a  query. 

binding 

An  explicit  established  association,  bonding,  or  tie. 

biometrics 

A  general  term  used  alternatively  to  describe  a  characteristic 
or  a  process. 

As  a  characteristic. 

A  measurable  biological  (anatomical  and  physiological)  and 
behavioral  characteristic  that  can  be  used  for  automated  rec¬ 
ognition. 

As  a  process'. 

Automated  methods  of  recognizing  an  individual  based  on 
measurable  biological  (anatomical  and  physiological)  and 
behavioral  characteristics. 

certificate  (secret) 

A  set  of  security-relevant  data  issued  by  a  security  authority 
or  a  trusted  third  party,  together  with  security  information 
which  is  used  to  provide  the  integrity  and  data  origin  authen¬ 
tication  services  for  the  data. 

circle  of  trust 

i.  A  set  of  criteria  established  for  joining  organizations 
within  a  federation  for  the  purposes  of  trusted  access  to 
each  other's  resources 

ii.  Federation  of  service  providers  and  identity  providers 
that  have  business  relationships  based  on  Liberty  architec¬ 
ture,  and  operational  agreements,  with  whom  users  can  trans¬ 
act  business  in  a  secure  and  seamless  environment. 

claim 

An  assertion  made  by  a  Claimant  of  the  value  or  values  of 
one  or  more  Identity  Attributes  of  a  Digital  Subject,  typically 
an  assertion  which  is  disputed  or  in  doubt. 

claimant 

i.  An  entity  which  is  or  represents  a  principal  for  the 
purposes  of  authentication.  A  claimant  includes  the  func¬ 
tions  necessary  for  engaging  in  authentication  exchanges 
on  behalf  of  a  principal. 

ii.  A  Digital  Subject  representing  a  Party  that  makes  a 
Claim. 
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Term  Definition(s) 


claim  authentication 
information 

Information  used  by  a  claimant  to  generate  exchange  AI 
needed  to  authenticate  a  principal. 

context 

A  property  that  can  be  associated  with  a  user  attribute  value 
to  specify  information  that  can  be  used  to  determine  the  ap¬ 
plicability  of  the  value. 

credential 

i.  An  identifiable  object  that  can  be  used  to  authenticate 
the  claimant  is  what  it  claims  to  be  and  authorize  the  claim¬ 
ant’s  access  rights 

ii.  Data  that  is  transferred  to  establish  the  claimed  identity 
of  an  entity. 

iii.  The  private  part  of  a  paired  Identity  assertion  (user-id  is 
usually  the  public  part).  The  thing(s)  that  an  Entity  relies 
upon  in  an  Assertion  at  any  particular  time,  usually  to  authen¬ 
ticate  a  claimed  Identity.  Credentials  can  change  over  time 
and  may  be  revoked.  Examples  include;  a  signature,  a  pass¬ 
word,  a  drivers  licence  number  (not  the  card  itself),  an  ATM 
card  number  (not  the  card  itself),  data  stored  on  a  smart-card 
(not  the  card  itself),  a  digital  certificate,  a  biometric  template. 

data  origin  authenti¬ 
cation 

Corroboration  that  the  source  of  data  received  is  as  claimed. 

delegation 

i.  Conveyance  of  privilege  from  one  entity  that  holds 
such  privilege,  to  another  entity. 

ii.  The  action  that  assigns  authority,  responsibility  or  a 
function  to  another  object. 

iii.  An  act  of  transferring  of  privileges  to  perform  some 
action  on  behalf  of  one  entity  to  another. 

digital  contract 

A  contract  made  in  digital  form  and  signed  by  two  entities 
between  whom  an  agreement  is  reached. 

digital  identity 

i.  The  digital  representation  of  the  information  known 
about  a  specific  individual,  group  or  organization 

ii.  A  digital  representation  of  a  set  of  Claims  made  by  one 
Party  about  itself  or  another  Digital  Subject. 

iii.  A  set  of  claims  made  by  one  digital  subject  about  itself 
or  another  digital  subject. 

digital  identity  pro¬ 
vider 

An  Agent  that  issues  a  Digital  Identity. 

digital  subject 

An  Entity  represented  or  existing  in  the  digital  realm  which  is 
being  described  or  dealt  with. 

directed  identity 

A  unifying  identity  system  must  support  both  “omni¬ 
directional”  identifiers  for  public  entities  and  “unidirectional” 
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Term 

Jefinition(s) 

identifiers  for  private  entities. 

discovery 

i.  The  act  of  locating  a  machine-processable  description 
of  a  network-related  resource  that  may  have  been  previ¬ 
ously  unknown  and  that  meets  certain  functional  criteria.  It 
involves  matching  a  set  of  functional  and  other  criteria  with 
a  set  of  resource  descriptions.  The  goal  is  to  find  an  appro¬ 
priate  Web  service-related  resource. 

ii.  The  process  by  which  IdM  resources  can  be  found  or 
located. 

electronic  identity 

The  information  about  a  registered  entity  that  the  Identity 
Provider  has  chosen  to  represent  the  Identity  of  that  entity. 

The  elD  includes  a  name  or  an  identifier  for  the  entity  that  is 
unique  within  the  domain  of  the  Identity  Provider. 

enrolment 

The  enrolment  of  an  entity  is  the  process  in  which  the  entity 
is  identified  and/or  other  attributes  are  corroborated. 

entity 

i.  Anything  that  has  separate  and  distinct  existence  that 
can  be  uniquely  identified.  In  the  context  of  IdM,  examples 
of  entities  include  subscribers,  users,  network  elements, 
networks,  software  applications,  services  and  devices.  An 
entity  may  have  multiple  identifiers. 

ii.  An  entity  is  anyone  (natural  or  legal  person)  or  any¬ 
thing  that  shall  be  characterised  through  the  measurement  of 
its  attributes. 

iii.  A  person,  physical  object,  animal,  or  juridical  entity. 

iv.  A  particular  thing,  such  as  a  person,  place,  process,  ob¬ 
ject,  concept,  association,  or  event. 

federation 

i.  An  act  of  establishing  a  relationship  between  two  or 
more  entities  or  an  association  compromising  any  number 
of  service  providers  and  identity  providers 

ii.  An  established  relationship  among  a  domain  of  a  single 
service  provider  or  among  NGN  providers. 

iii.  A  federation  is  a  collection  of  realms  that  have  estab¬ 
lished  a  producer-consumer  relationship  whereby  one  realm 
can  provide  authorized  access  to  a  resource  it  manages  based 
on  an  identity,  and  possibly  associated  attributes,  that  are  as¬ 
serted  in  another  realm.  A  federation  requires  trust  such  that  a 
Relying  Party  can  make  a  well-informed  access  control  deci¬ 
sion  based  on  the  credibility  of  identity  and  attribute  data  that 
is  vouched  for  by  another  realm. 

federated  identity 

i.  A  collective  term  describing  agreements  standards  and 
technologies  that  make  identity  and  entitlements  portable 
across  autonomous  domains 

ii.  A  single  user  identity  that  can  be  used  to  access  a  group 
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of  services  or  applications  that  are  bounded  by  the  ties  and 
conditions  of  a  federation. 

iii.  A  shared  Identity  and/or  authentication,  as  the  result  of 
federation  by  either  the  Entity  or  by  two  or  more  organisa¬ 
tions. 

identification 

The  process  of  verifying  the  identity  of  a  user,  process,  or 
device,  usually  as  a  prerequisite  for  granting  access  to  re¬ 
sources  in  an  IT  system. 

identification  ser¬ 
vices 

Services  that  aggregate  an  entity’s  identities  to  provide  trust 
levels  in  the  bindings  between  those  identities  and  the  entity. 

identifier 

i.  An  identifier  is  a  series  of  digits,  characters  and  sym¬ 
bols  or  any  other  form  of  data  used  to  identify  subscriber  (s), 
user(s),  network  element(s),  function(s),  network  entity(ies) 
providing  services/applications,  or  other  entities  (e.g., 
physical  or  logical  objects). 

ii.  A  data  object  (for  example,  a  string)  mapped  to  a  sys¬ 
tem  entity  that  uniquely  refers  to  the  system  entity.  A  system 
entity  may  have  multiple  distinct  identifiers  referring  to  it.  An 
identifier  is  essentially  a  "distinguished  attribute"  of  an  entity. 

iii.  Either  an  "http"  or  "https"  URI,  (commonly  referred  to 
as  a  "URL"  within  this  document),  or  an  XRI  (Reed,  D.  and 

D.  McAlpin,  “Extensible  Resource  Identifier  (XRI)  Syntax 
V2.0,”.) 

iv.  Strings  or  tokens  that  are  unique  within  a  given  scope 
(globally  or  locally  within  a  specific  domain,  community, 
directory,  application,  etc.).  Identifiers  are  the  key  used  by 
the  parties  to  an  identification  relationship  to  agree  on  the 
entity  being  represented.  Identifiers  may  be  classified  as  om¬ 
nidirectional  and  unidirectional.  Omnidirectional  identifiers 
are  intended  to  be  public  and  easily  discoverable,  while  uni¬ 
directional  identifiers  are  intended  to  be  private  and  used  only 
in  the  context  of  a  specific  identity  relationship.  Identifiers 
may  also  be  classified  as  resolvable  or  non-resolvable.  Re¬ 
solvable  identifiers,  such  as  a  domain  name  or  e-mail  address, 
may  be  dereferenced  into  the  entity  they  represent.  Non- 
resolvable  identifiers,  such  as  a  person's  real-world  name,  or 

a  subject  or  topic  name,  can  be  compared  for  equivalence  but 
are  not  otherwise  machine-understandable.  There  are  many 
different  schemes  and  formats  for  digital  identifiers.  The 
most  widely  used  is  Uniform  Resource  Identifier  (URI)  and 
its  internationalized  version  Internationalized  Resource  Iden¬ 
tifier  (IRI) — the  standard  for  identifiers  on  the  World  Wide 
Web.  OpenID  and  Light-Weight  Identity  (LID)  are  two  web 
authentication  protocols  that  use  standard  HTTP  URIs  (often 

K-6 


Term 

)efinition(s) 

called  URLs),  for  example.  A  new  OASIS  standard  for  ab¬ 
stract,  structured  identifiers,  XRI  (Extensible  Resource  Iden¬ 
tifiers),  adds  new  features  to  URIs  and  IRIs  that  are 
especially  useful  for  digital  identity  systems.  OpenlD 

V.  An  attribute  or  a  set  of  attributes  of  an  entity  which 
uniquely  identifies  the  entity  within  a  certain  context.  (For 
the  sake  of  clarity,  identifiers  consisting  of  one  attribute  are 
also  characteristics;  they  distinguish  an  entity  from  other  enti¬ 
ties.  An  entity  may  have  multiple  distinct  identifiers  referring 
to  it.  Identifiers  uniquely  identify  an  entity,  while  characteris¬ 
tics  do  not  need  to.  However,  it  should  be  noted  that  identifi¬ 
ers  can  consist  of  a  combination  of  attributes,  whereas 
characteristics  are  always  one  single  attribute.) 

identity 

i.  Structured  representations  of  an  entity  in  the 
form  of  one  or  more  credentials,  identifiers,  attributes,  or 
patterns  in  a  relevant  context.  Such  representations  can 
take  any  physical  or  electro-optical  (digital  or  analog) 
form  or  syntax,  and  may  have  associated  implicit  or  ex¬ 
plicit  time-stamp  and  location  specifications. 

ii.  The  properties  of  an  entity  that  allows  it  to  be  distin¬ 
guished  from  other  entities. 

iii.  The  attributes  by  which  an  entity  is  described,  recog¬ 
nized  or  known. 

iv.  The  essence  of  an  entity  and  often  described  by  its 
characteristics. 

V.  The  essence  of  an  entity  [Merriam].  One's  identity  is 

often  described  by  one's  characteristics,  among  which  may  be 
any  number  of  identifiers. 

vi.  The  fundamental  concept  of  uniquely  identifying  an 
object  (person,  computer,  etc.)  within  a  context.  That  context 
might  be  local  (within  a  department),  corporate  (within  an 
enterprise),  national  (within  the  bounds  of  a  country),  global 
(all  such  object  instances  on  the  planet),  and  possibly  univer¬ 
sal  (extensible  to  environments  not  yet  known).  Many  identi¬ 
ties  exist  for  local,  corporate,  and  national  domains.  Some 
globally  unique  identifiers  exist  for  technical  environments, 
often  computer-generated. 

vii.  A  collection  of  attributes  which  helps  to  distinguish 
one  entity  from  another. 

identity  agent 

Manages  and  supports  a  consistent  user  experience  (and  in 
some  cases  other  kinds  of  interactions)  with  a  Service  Pro¬ 
vider. 

identity  attribute 

A  property  of  a  Digital  Subject  that  may  have  zero  or  more 
values. 
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identity  based  secu¬ 
rity  policy 

A  security  policy  based  on  the  identities  and/or  attributes  of 
users,  a  group  of  users,  or  entities  acting  on  behalf  of  the  us¬ 
ers  and  the  resources/objects  being  accessed. 

identity  bridge  pro¬ 
vider 

An  Identity  Provider  that  acts  as  a  trusted  intermediary 
among  other  Identity  Providers. 

identity  context 

The  surrounding  environment  and  circumstances  that  deter¬ 
mine  meaning  of  Digital  Identities  and  the  policies  and  proto¬ 
cols  that  govern  their  interactions. 

identity  information 

All  the  information  identifying  a  user,  including  trusted  (net¬ 
work  generated)  and/or  untrusted  (user  generated)  addresses. 
Identity  information  shall  take  the  form  of  either  a  SIP  URI 
(see  RFC  2396)  or  a  "tel"  URI  fsee  RFC  3966). 

identity  defederation 

The  action  occurring  when  Providers  agree  to  stop  referring 
to  an  entity  via  a  certain  set  of  identifiers  and/or  attributes. 

identity  federation 

The  act  of  creating  a  federated  identity  on  behalf  of  an  entity. 

identity  layer 

A  common  layer  where  identity  information  can  be  ex¬ 
changed  between  different  systems. 

identity  management 

The  combination  of  technical  systems,  rules  and  procedures 
that  define  the  ownership,  utilization,  and  safeguard  of  per¬ 
sonal  identity  information.  The  primary  goal  of  the  Identity 
Management  process  is  to  assign  attributes  to  a  digital  iden¬ 
tity,  and  to  connect  that  identity  to  an  individual. 

identity  pattern 

A  structured  expression  derived  from  the  behaviour  of  an 
entity  that  contributes  to  the  recognition  process;  this  may 
include  the  reputation  of  the  entity.  Identity  patterns  may  be 
uniquely  associated  with  an  entity,  or  a  class  with  which  the 
entity  is  associated. 

identity  proofing 

A  shareable,  identity  management  component  by  which  the 
credential  issuer  validates  sufficient  information  to  uniquely 
identify  a  person  applying  for  the  credential. 

identity  provider 

i.  An  entity  that  creates,  maintains,  and  manages  trusted 
identity  information  for  entities.  An  Identity  Provider  may 
include  a  Trusted  Third  Party  as  well  as  Relying  Parties 
and  entities  themselves  in  different  contexts. 

ii.  A  type  of  service  provider  that  creates,  maintains,  and 
manages  identity  information  for  users/devices  and  provides 
user/device  authentication. 

iii.  A  service  provider  that  authenticates  a  user  and  that 
creates,  maintains,  and  manages  identity  information  for  us¬ 
ers  and  asserts  user  authentication  and  other  identity  related 
information  to  other  trusted  service  providers. 
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iv.  An  entity  in  an  AAI  that  performs  Identity  Manage¬ 
ment. 

V.  Kind  of  service  provider  that  creates,  maintains,  and 
manages  identity  information  for  principals  and  provides  au¬ 
thentication  to  other  service  providers  within  a  federation, 
such  as  with  web  browser  profiles. 

identity  registration 

The  process  of  making  a  person’s  identity  known  to  the  (Per¬ 
sonal  Identity  Verification)  system,  associating  a  unique 
identifier  with  that  identity,  and  collecting  and  recording  the 
person’s  relevant  attributes  into  the  system. 

identity  verification 

The  process  of  affirming  that  a  claimed  identity  is  correct  by 
comparing  the  offered  claims  of  identity  with  previously 
proven  information. 

internationalization 

The  process  of  planning  and  implementing  Identity  Manage¬ 
ment  specifications,  products,  services,  and  administrative 
implementations  so  that  they  can  easily  be  adapted  to  specific 
local  technical  platforms,  languages,  and  cultures,  a  process 
called  localization. 

interoperability 

The  ability  of  independent  systems  to  exchange  meaningful 
information  and  initiate  actions  from  each  other,  in  order  to 
operate  together  to  mutual  benefit.  In  particular,  it  envisages 
the  ability  for  loosely-coupled  independent  systems  to  be  able 
to  collaborate  and  communicate;  the  possibility  of  use  in  ser¬ 
vices  outside  the  direct  control  of  the  issuing  assigner. 

layer  network 

A  "topological  component"  that  represents  the  complete  set 
of  access  groups  of  the  same  type  which  may  be  associated 
for  the  purpose  of  transferring  information. 

manifestation 

An  observed  or  discovered  (i.e.,  not  self- asserted)  representa¬ 
tion  of  an  entity’s  identity  or  claim.  (Compare  with  asser¬ 
tion.) 

mutual  authentica¬ 
tion 

Requirement  that  both  the  service  provider  and  the  user  iden¬ 
tify  each  other. 

data 

A  relationship  that  someone  claims  to  exist  between  two  enti¬ 
ties. 

name 

A  name  is  the  identifier  of  an  entity  (e.g.,  subscriber,  network 
element)  that  may  be  resolved/translated  into  an  address. 

network  transpar¬ 
ency 

The  ability  of  a  protocol  to  transmit  data  over  the  network  in 
a  manner  which  is  transparent  to  those  using  the  applications 
that  are  using  the  protocol. 

non-repudiation 

i.  The  ability  to  prove  an  action  or  event  has  taken 

place,  so  that  this  event  or  action  cannot  be  repudiated  later 
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ii.  The  ability  through  historical  logs  and  logical  analysis 
to  prevent  or  discourage  an  Entity  from  denying  that  it  had 
acted  as  an  Identity  in  a  given  transaction,  especially  in  a  le¬ 
gal  sense. 

object 

i.  A  well-defined  piece  of  information,  definition,  or 

specification  which  requires  a  name  in  order  to  identify  its 
use  in  an  instance  of  communication  and  identity  manage- 
ment  processing. 

ii.  Entity  within  the  scope  of  the  DOI  system;  the  entity 
may  be  abstract,  physical  or  digital,  as  any  of  these  forms  of 
entity  may  be  of  relevance  in  content  management  (e.g.,  peo¬ 
ple,  resources,  agreements). 

owner 

The  registered  Entity  for  an  Identity. 

party 

A  natural  person  or  a  legal  entity. 

path  layer  network 

A  "layer  network"  which  is  independent  of  the  transmission 
media  and  which  is  concerned  with  the  transfer  of  informa¬ 
tion  between  path  layer  network  "access  points." 

peer-entity  authenti¬ 
cation 

The  corroboration  that  a  peer  entity  in  an  association  is  the 
one  claimed. 

persistent 

Existing,  and  able  to  be  used  in  services  outside  the  direct 
control  of  the  issuing  assigner,  without  a  stated  time  limit. 

personally  identifi¬ 
able  information 
(PII) 

i.  The  information  pertaining  to  any  person  which 
makes  it  possible  to  identify  such  individual  (including  the 
information  capable  of  identifying  a  person  when  combined 
with  other  information  even  if  the  information  does  not 
clearly  identify  the  person).  Note:  Information  that  can  be 
used  to  identify  an  individual  should  be  defined  by  national 
legislation. 

ii.  Any  information  which  identifies  a  person  to  any 
degree. 

policy 

A  set  of  Rules,  usually  associated  with  a  Role  or  other  dy¬ 
namic  attributes. 

presence 

i.  A  set  of  attributes  that  characterize  an  entity  (main¬ 

tained  by  a  “presentity”)  relating  to  current  activity,  environ¬ 
ment,  geolocation,  communication  means  and  contact 
addresses. 

ii.  A  set  of  data  representing  the  status  and  availability 

of  a  user  or  a  group  of  users  for  communication. 

presentity 
(presence  entity) 

An  entity  that  makes  presence  information  available  for  use 
by  others. 
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Any  uniquely  identifiable  entity  that  is  capable  of 
providing  presence  information  to  presence  service.  Exam¬ 
ples  of  presentities  are  devices,  services  etc. 

principal 

An  entity  whose  identity  can  be  authenticated. 

privacy 

i.  The  right  of  entities  to  control  or  influence  what  in¬ 
formation  related  to  them  may  be  collected  and  stored  also 
by  whom  and  to  whom  that  information  may  be  disclosed. 

ii.  Ensuring  that  information  about  a  person  is  protected  in 
accordance  with  national,  regional,  or  global  regulations. 

Such  information  may  be  contained  within  a  message,  but 
may  also  be  inferred  from  patterns  of  communication;  e.g., 
when  communications  happen,  the  types  of  resource  ac¬ 
cessed,  the  parties  with  whom  communication  occurs,  etc. 

iii.  A  right  to  control  the  dissemination  of  the  attributes  of 
an  entity. 

iv.  The  rights  and  limitations  of  access  to  and  processing 
of  personal  data. 

v.  Proper  handling  of  personal  information  throughout  its 
life  cycle,  consistent  with  the  preferences  of  the  subject. 

privacy  policy 

i.  The  policy  statement  that  defines  the  rules  for  protect¬ 
ing  access  to  and  dissemination  of  personal  privacy  infor¬ 
mation 

ii.  A  set  of  rules  and  practices  that  specify  or  regulate  how 
a  person  or  organization  collects,  processes  (uses)  and  dis¬ 
closes  another  party's  personal  data  as  a  result  of  an  interac¬ 
tion. 

private  (subscriber) 
identity 

An  identity  derived  from  the  IMSI. 

private  identifier 

A  Claimed  Identifier  that  is  intended  to  be  private  informa¬ 
tion  used  only  the  context  of  the  End  User’s  relationship  with 
one  or  more  specific  Relying  Parties  (typically  one  or  a  small 
number).  The  use  of  Private  Identifiers  reduces  or  eliminates 
the  ability  of  multiple  Relying  Parties  to  do  correlation  of  an 
End  User. 

Privilege 

i.  A  right  to  carry  out  a  particular  permission  (act)  that 
is  assigned  to  a  role  with  some  constraints  or  conditions.  A 
role  is  (can  be)  associated  with  multiple  privileges. 

ii.  An  attribute  or  property  assigned  to  an  entity  by  an  au¬ 
thority. 

iii.  An  authorization  or  set  of  authorizations  to  perform 
security-relevant  functions. 

proofing 

The  verification  or  validation  of  information  when  enrolling 
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new  entities  into  identity  systems. 

provisioning 

Automatically  providing  an  Identity  with  access  to  a  role, 
resource  or  service,  or  automatically  changing  or  removing 
that  access,  based  on  the  life  cycle  of  events  or  work  requests 
or  changed  attributes. 

pseudonym 

A  fictitious  identity  that  an  Entity  creates  for  itself,  whereby 
the  Entity  can  remain  pseudonymous,  or  perhaps  even  fully 
anonymous,  in  certain  contexts. 

public  (subscriber) 
identity 

Either  a  SIP  URI  or  a  tel  URI. 

public  service  identi¬ 
fier 

Either  a  SIP  URI  or  a  tel  URI. 

quality  of  assurance 

See  “assurance  level.” 

relying  party 

i.  An  entity  that  relies  on  an  identity  representation  or 
claim  by  a  Requesting/  Asserting  entity  within  some  re¬ 
quest  context. 

ii.  A  user  or  agent  that  relies  on  the  data  in  a  certificate  in 
making  decisions. 

iii.  A  Party  that  makes  known  through  its  Agent  one  or 
more  alternative  sets  of  Claims  that  it  desires  or  requires,  and 
receives  through  this  same  Agent  a  Digital  Identity  purport¬ 
edly  including  the  required  Claims  from  a  Digital  Identity 
Provider  or  other  Agent  of  another  Party. 

iv.  The  entity  that  relies  on  the  result  of  an  authentication. 
Usually,  but  not  always,  the  same  as  the  authenticating  party 
and  service  provider. 

v.  Recipient  of  a  certificate  who  acts  in  reliance  on  that 
certificate  and/or  digital  signatures  verified  using  that  certifi¬ 
cate  (see  IETF  RFC  3647). 

vi.  The  recipient  of  a  message  that  relies  on  a  request  mes¬ 
sage  and  associated  assertions  to  determine  whether  to  pro¬ 
vide  a  requested  service. 

repudiation 

i.  Denial  by  one  of  the  entities  involved  in  a  communica¬ 
tion  of  having  participated  in  all  or  part  of  the  communica¬ 
tion 

ii.  An  ability  to  provide  public  notice  that  identity  creden¬ 
tials,  identifiers,  attributes,  or  patterns  have  been  revoked  or 
not  valid. 

iii.  An  entity  involved  in  a  communication  exchange  sub¬ 
sequently  denies  the  fact. 

requesting  entity 

An  Entity  making  an  identity  representation  or  claim  to  a  re¬ 
lying  party  within  some  request  context. 
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revocation 

The  act  (by  someone  having  the  authority)  of  annulling  some¬ 
thing  previously  done. 

role 

A  set  of  properties  or  attributes  that  describes  the  capabili¬ 
ties  of  an  entity  that  can  be  performed.  An  activity  per¬ 
formed  by  an  entity;  each  entity  can  play  many  roles. 

A  position  or  function  of  an  organization  that  describes  the 
authority  and  responsibility  conferred  on  an  entity  assigned  to 
the  role. 

security  domain 

A  set  of  elements,  a  security  policy,  a  security  authority  and  a 
set  of  security -relevant  activities  in  which  the  elements  are 
managed  in  accordance  with  the  security  policy.  The  policy 
will  be  administered  by  the  security  authority.  A  given  secu¬ 
rity  domain  may  span  multiple  security  zones. 

security  zone 

A  protected  area.  This  is  defined  by  operational  control,  loca¬ 
tion,  and  connectivity  to  other  device/network  elements. 

security  domain  au¬ 
thority 

A  security  authority  that  is  responsible  for  the  implementa¬ 
tion  of  a  security  policy  for  a  security  domain. 

self-asserted  identity 

An  identity  asserted  by  an  entity  itself. 

service 

A  set  of  functions  and  facilities  offered  to  a  user  by  a  pro¬ 
vider. 

symmetric  authenti¬ 
cation  method 

A  method  of  authentication  in  which  both  entities  share 
common  authentication  information. 

terminal  object 

An  object  having  a  binding  to  a  terminal  device,  such  as  a 
Subscriber  Identity  Module  (SIM)  card. 

trail 

A  “transport  entity”  which  consists  of  an  associated  pair  of 
“unidirectional  trails”  capable  of  simultaneously  transferring 
information  in  opposite  directions  between  their  respective 
inputs  and  outputs. 

transmission  media 
layer  network 

A  “layer  network”  which  may  be  media  dependent  and  which 
is  concerned  with  the  transfer  of  information  between  trans¬ 
mission  media  layer  network  “access  points”  in  support  of 
one  or  more  “path  layer  networks.” 

transport 

The  functional  process  of  transferring  information  between 
different  locations. 

transport  entity 

An  architectural  component  which  transfers  information  be¬ 
tween  its  inputs  and  outputs  within  a  layer  network. 

transport  network 

The  functional  resources  of  the  network  which  conveys  user 
information  between  locations. 

trust 

i.  A  measure  of  reliance  on  the  character,  ability,  strength, 

or  truth  of  someone  or  something. 
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ii.  Confidence  that  an  entity  will  behave  in  a  particular 
way  with  respect  to  certain  activities  (entity  X  is  said  to  trust 
entity  Y  for  a  set  of  activities  if  and  only  if  entity  X  relies 
upon  entity  Y  behaving  in  a  particular  way  with  respect  to  the 
activities.) 

iii.  A  reasonable  level  of  confidence  that  an  entity  will  be¬ 
have  in  a  certain  manner  in  a  given  context. 

iv.  A  subjective  assessment.  An  instance  of  a  relationship 
between  two  or  more  entities,  in  which  an  entity  assumes  that 
another  entity  will  act  as  authorised/expected. 

v.  Trust  is  an  evaluation,  by  an  entity,  of  the  reliability  of 
an  identity  when  the  identity  is  involved  in  interactions. 

trust  level 

A  consistent,  quantifiable  measure  of  reliance  on  the  charac¬ 
ter,  ability,  strength,  or  truth  of  someone  or  something. 

trusted  but  vulner¬ 
able  zone 

From  the  viewpoint  of  a  NGN  provider  a  security  zone  where 
the  network  elements/devices  are  operated  (provisioned  and 
maintained)  by  the  NGN  provider.  The  equipment  may  be 
under  the  control  by  either  the  customer/subscriber  or  the 

NGN  provider.  In  addition,  the  equipment  may  be  located 
within  or  outside  the  NGN  provider’s  domain.  They  commu¬ 
nicate  with  elements  both  in  the  trusted  zone  and  with  ele¬ 
ments  in  the  un-trusted  zone,  which  is  why  they  are 
“vulnerable.”  Their  major  security  function  is  to  protect  the 
NEs  in  the  trusted  zone  from  the  security  attacks  originated  in 
the  un-trusted  zone  in  a  fail-safe  manner. 

trusted  entity 

An  entity  that  can  violate  a  security  policy,  either  by  perform¬ 
ing  actions  which  it  is  not  supposed  to  do,  or  by  failing  to 
perform  actions  which  it  is  supposed  to  do. 

trusted  identity  in¬ 
formation 

Network-generated  user  public  identity  information. 

trusted  third  party 

A  security  authority  or  its  agent  that  is  trusted  with  respect  to 
some  security  relevant  activities  (in  the  context  of  a  security 
policy). 

trusted  zone 

From  the  viewpoint  of  a  NGN  provider  a  security  domain 
where  a  NGN  provider’s  network  elements  and  systems  re¬ 
side  and  never  communicate  directly  with  customer  equip¬ 
ment.  The  common  characteristics  of  NGN  network  elements 
in  this  domain  are  that  they  are  under  the  full  control  of  the 
related  NGN  provider,  are  located  in  the  NGN  provider 
premises  (which  provides  physical  security),  and  they  com¬ 
municate  only  with  elements  in  the  “trusted”  domain  and 
with  elements  in  the  “trusted-but-vulnerable”  domain. 

untrusted  zone 

From  the  viewpoint  of  a  NGN  provider  a  zone  that  includes 

K-14 


Term 

)efinition(s) 

all  network  elements  of  customer  networks  or  possibly  peer 
networks  or  other  NGN  provider  zones  outside  of  the  original 
domain,  which  are  connected  to  the  NGN  provider’s  border 
elements. 

user 

i.  Includes  end  user,  person,  subscriber,  system,  equip¬ 
ment,  terminal  (e.g.,  FAX,  PC),  (functional )  entity,  process, 
application,  provider,  or  corporate  network. 

ii.  An  Identity  where  the  identifier  of  the  identity  is  the 
public  part  of  a  paired  Identity  assertion. 

user  identifiers 

Identifiers  that  represent  users  in  their  interactions  with  other 
parties.  Users  may  present  their  identifiers  verbally,  on  paper, 
on  plastic  cards,  or  in  any  other  appropriate  manner.  Elec¬ 
tronic  user  identifiers  are  electronically  presented  over  data 
communication  channels  by  user-operated  computing  devices 
(client  devices)  such  as  PCs,  laptops,  mobile  phones,  and 
smartcards. 

user  identity 

A  code  or  string  uniquely  identifying  a  user  across  a  multi¬ 
user,  multi-service  infrastructure. 

verification 

The  process  of  confirming  a  claimed  Identity.  For  example; 
any  one-to-one  precise  matching  of  an  identity’s  registered 
credentials,  such  as  in  a  logon  or  any  non-AFIS  process. 
Usually  performed  in  real-time,  with  a  yes/no  outcome. 

verification  authen¬ 
tication  information 
(verification  AI) 

Information  used  by  a  verifier  to  verify  an  identity  claimed 
through  exchange  AI. 

verifier 

An  entity  that  is  or  represents  the  entity  requiring  an  authen¬ 
ticated  identity.  A  verifier  includes  the  functions  necessary 
for  engaging  in  authentication  exchanges. 
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ABACWG 

ANSI 

AWG 

CAC 

CDC 

CIO 

CJIS 

CONOPS 

CPMWG 

DHS 

DOC 

DOD 

DOE 

DOJ 

DOS 

EPTWG 

FAA 


Attribute  Based  Access  Control  Working  Group 

American  National  Standards  Institute 

GSAHSPD-12  architecture  working  group 

Common  Access  Card 

Centers  for  Disease  Control  and  Prevention 

Chief  Information  Officer 

Criminal  Justice  Information  Services 

Concept  of  Operations 

DOD  PKI  Certificate  Policy  Management  Working 
Group 

Department  of  Homeland  Security 
Department  of  Commerce 
Department  of  Defense 
Department  of  Energy 
Department  of  Justice 
Department  of  State 

Evaluation  Program  Technical  Working  Group 
Federal  Aviation  Administration 
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FBCA 

Federal  Bridge  Certificate  Authority 

FBI 

Federal  Bureau  of  Investigation 

FEA 

Federal  Enterprise  Architecture 

FICC 

Federal  Identity  Credential  Committee 

FIPS 

Federal  Information  Processing  Standard 

FISMA 

Federal  Infonnation  Security  Management  Act 

FRAC 

First  Responder’s  Access  Card 

FTC 

Federal  Trade  Commission 

GIG 

Global  Infonnation  Grid 

GSA 

General  Services  Administration 

GTG 

Global  Telecommunications  Grid 

HHS 

Department  of  Health  and  Human  Services 

HIPAA 

Health  Insurance  Portability  and  Accountability  Act 

HR 

Human  Resources 

IA 

Information  Assurance 

ICCP 

Committee  for  Information,  Computer  and  Communi¬ 
cations  Policy 

ICT 

Information  and  Communications  Technology 

IdM 

Identity  Management 

IdMN 

IdM  Network 
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IPMSCG 

IRS 

ISE 

ISO 

ISO/IEC/JTC 1/SC27 

IT 

ITU 

ITU-D 

ITU-R 

ITU-T 

NASA 

NIH 

NIST 

NO  A  A 

NSF 

NSS 

NSTC 

OECD 

OMB 


DOD  Identity  Protection  and  Management  Senior  Co¬ 
ordinating  Group 

Internal  Revenue  Service 

Information  Sharing  Environment 

International  Organization  for  Standardization 

IT  Security  Techniques 

Information  Technology 

International  Telecommunication  Union 

Development  Sector 

Radiocommunication  Sector 

Telecommunication  Sector 

National  Aeronautics  and  Space  Administration 

National  Institutes  of  Health 

National  Institute  of  Standards  and  Technology 

National  Oceanic  and  Atmospheric  Administration 

National  Science  Foundation 

National  Security  System 

National  Science  and  Technology  Committee 

Organization  for  Economic  Cooperation  and  Devel¬ 
opment 

Office  of  Management  and  Budget 
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OPM 

Office  of  Personnel  Management 

PIA 

Privacy  Impact  Assessment 

PII 

Personally  Identifiable  Information 

PIN 

Personal  Identification  Number 

PIV 

Personal  Identity  Verification 

PKI 

Public  Key  Infrastructure 

PSTN 

Public-Switched  Telecommunications  Network 

SCA 

SmartCard  Alliance 

SDO 

Standards  Development  Organization 

SG17 

ITU-T  standards  group  on  security 

SIA 

Security  Industry  Alliance  (SIA) 

SOA 

Service  Oriented  Architecture 

SORN 

System  of  Records  Notice 

SSA 

Social  Security  Administration 

SSN 

Social  Security  number 

STAR 

Staff  Time  and  Activity  Reporting 

TSP 

Thrift  Savings  Plan 

TWIG 

Transportation  Worker  Identification  Card 

VA 

Department  of  Veterans  Affairs 

WPISP 

Working  Party  on  Infonnation  Security  and  Privacy 
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